User feedback system and method

ABSTRACT

A user feedback system for a user of a delivery device within a delivery ecosystem includes an obtaining processor adapted to obtain one or more user factors indicative of a state of the user, wherein the one or more user factors are based upon at least a first aspect of a situation of the user separate to a handling or operation of the delivery device by the user; and an estimation processor adapted to identify a corresponding feedback action expected to alter a state of the user as indicated at least in part by the or each user factor.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a National Phase entry of PCT Application No.PCT/GB2021/051493, filed Jun. 15, 2021, which claims priority from GreatBritain Application No. 2009486.8, filed Jun. 22, 2020, each of which ishereby fully incorporated herein by reference.

TECHNICAL FIELD

The present disclosure relates to a user feedback system and method fora user of a delivery device.

BACKGROUND

The “background” description provided herein is for the purpose ofgenerally presenting the context of the disclosure. Work of thepresently named inventors, to the extent it is described in thisbackground section, as well as aspects of the description which may nototherwise qualify as prior art at the time of filing, are neitherexpressly or impliedly admitted as prior art against the presentdisclosure.

Aerosol provision systems are popular with users as they enable thedelivery of active ingredients (such as nicotine) to the user in aconvenient manner and on demand.

As an example of an aerosol provision system, electronic cigarettes(e-cigarettes) generally contain a reservoir of a source liquidcontaining a formulation, typically including nicotine, from which anaerosol is generated, e.g. through heat vaporization. An aerosol sourcefor an aerosol provision system may thus comprise a heater having aheating element arranged to receive source liquid from the reservoir,for example through wicking/capillary action. Other source materials maybe similarly heated to create an aerosol, such as botanical matter, or agel comprising an active ingredient and/or flavoring. Hence moregenerally, the e-cigarette may be thought of as comprising or receivinga payload for heat vaporization.

While a user inhales on the device, electrical power is supplied to theheating element to vaporize the aerosol source (a portion of thepayload) in the vicinity of the heating element, to generate an aerosolfor inhalation by the user. Such devices are usually provided with oneor more air inlet holes located away from a mouthpiece end of thesystem. When a user sucks on a mouthpiece connected to the mouthpieceend of the system, air is drawn in through the inlet holes and past theaerosol source. There is a flow path connecting between the aerosolsource and an opening in the mouthpiece so that air drawn past theaerosol source continues along the flow path to the mouthpiece opening,carrying some of the aerosol from the aerosol source with it. Theaerosol-carrying air exits the aerosol provision system through themouthpiece opening for inhalation by the user.

Usually an electric current is supplied to the heater when a user isdrawing/puffing on the device. Typically, the electric current issupplied to the heater, e.g. resistance heating element, in response toeither the activation of an airflow sensor along the flow path as theuser inhales/draw/puffs or in response to the activation of a button bythe user. The heat generated by the heating element is used to vaporizea formulation. The released vapor mixes with air drawn through thedevice by the puffing consumer and forms an aerosol. Alternatively or inaddition, the heating element is used to heat but typically not burn abotanical such as tobacco, to release active ingredients thereof as avapor/aerosol.

How the user interacts with the e-cigarette (for example the amount ofvaporized/aerosolized payload consumed by the user, and/or their patternof use), and their actual or perceived utility from the interaction, maybe influenced by the user's state, which at least in part may beexpressed colloquially as their mood(s) and/or subjective need(s).

Consequently it would be useful to provide a delivery mechanism that wasmore responsive to the user's state.

SUMMARY

In a first aspect, a user feedback system for a user of a deliverydevice within a delivery ecosystem is provided.

In another aspect, a user feedback method for a user of a deliverydevice within a delivery ecosystem is provided.

Further respective aspects and features of the disclosure are defined inthe appended claims.

It is to be understood that both the foregoing general summary of thedisclosure and the following detailed description are indicative, butare not restrictive, of the disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete appreciation of the disclosure and many of the attendantadvantages thereof will be readily obtained as the same becomes betterunderstood by reference to the following detailed description whenconsidered in connection with the accompanying drawings, wherein:

FIG. 1 is a schematic diagram of a delivery device in accordance withembodiments of the description.

FIG. 2 is a schematic diagram of a body of a delivery device inaccordance with embodiments of the description.

FIG. 3 is a schematic diagram of a cartomizer of a delivery device inaccordance with embodiments of the description.

FIG. 4 is a schematic diagram of a body of a delivery device inaccordance with embodiments of the description.

FIG. 5 is a schematic diagram of a delivery ecosystem in accordance withembodiments of the description.

FIG. 6 is a schematic diagram of a user feedback system in accordancewith embodiments of the description.

FIG. 7 is a flow diagram of a user feedback method for a user of adelivery device within a delivery ecosystem, in accordance withembodiments of the description.

DETAILED DESCRIPTION

A user feedback system and method is disclosed. In the followingdescription, a number of specific details are presented in order toprovide a thorough understanding of the embodiments of the presentdisclosure. It will be apparent, however, to a person skilled in the artthat these specific details need not be employed to practice embodimentsof the present disclosure. Conversely, specific details known to theperson skilled in the art are omitted for the purposes of clarity whereappropriate.

As described above, the present disclosure relates to a user feedbacksystem. This user feedback system is for improving the responsiveness ofa delivery device for a user.

The term ‘delivery device’ may encompass systems that deliver a leastone substance to a user, and include non-combustible aerosol provisionsystems that release compounds from an aerosol-generating materialwithout combusting the aerosol-generating material, such as electroniccigarettes, tobacco heating products, and hybrid systems to generateaerosol using a combination of aerosol-generating materials; andaerosol-free delivery systems that deliver the at least one substance toa user orally, nasally, transdermally or in another way without formingan aerosol, including but not limited to, lozenges, gums, patches,articles comprising inhalable powders, and oral products such as oraltobacco which includes snus or moist snuff, wherein the at least onesubstance may or may not comprise nicotine.

The substance to be delivered may be an aerosol-generating material or amaterial that is not intended to be aerosolized. As appropriate, eithermaterial may comprise one or more active constituents, one or moreflavors, one or more aerosol-former materials, and/or one or more otherfunctional materials.

Currently, the most common example of such a delivery device is anaerosol provision system (e.g. a non-combustible aerosol provisionsystem) or electronic vapor provision system (EVPS), such as ane-cigarette. Throughout the following description the term “e-cigarette”is sometimes used but this term may be used interchangeably withdelivery device except where stated otherwise or where context indicatesotherwise. Similarly the terms ‘vapor’ and ‘aerosol’ are referred toequivalently herein.

Generally, the electronic vapor/aerosol provision system may be anelectronic cigarette, also known as a vaping device or electronicnicotine delivery device (END), although it is noted that the presenceof nicotine in the aerosol-generating (e.g. aerosolizable) material isnot a requirement. In some embodiments, a non-combustible aerosolprovision system is a tobacco heating system, also known as aheat-not-burn system. An example of such a system is a tobacco heatingsystem. In some embodiments, the non-combustible aerosol provisionsystem is a hybrid system to generate aerosol using a combination ofaerosol-generating materials, one or a plurality of which may be heated.Each of the aerosol-generating materials may be, for example, in theform of a solid, liquid or gel and may or may not contain nicotine. Insome embodiments, the hybrid system comprises a liquid or gelaerosol-generating material and a solid aerosol-generating material. Thesolid aerosol-generating material may comprise, for example, tobacco ora non-tobacco product. Meanwhile in some embodiments, thenon-combustible aerosol provision system generates a vapor/aerosol fromone or more such aerosol-generating materials.

Typically, the non-combustible aerosol provision system may comprise anon-combustible aerosol provision device and an article (otherwisereferred to as a consumable) for use with the non-combustible aerosolprovision system. However, it is envisaged that articles whichthemselves comprise a means for powering an aerosol generating component(e.g. an aerosol generator such as a heater, vibrating mesh or the like)may themselves form the non-combustible aerosol provision system. In oneembodiment, the non-combustible aerosol provision device may comprise apower source and a controller. The power source may be an electric powersource or an exothermic power source. In one embodiment, the exothermicpower source comprises a carbon substrate which may be energized so asto distribute power in the form of heat to an aerosolizable material orheat transfer material in proximity to the exothermic power source. Inone embodiment, the power source, such as an exothermic power source, isprovided in the article so as to form the non-combustible aerosolprovision. In one embodiment, the article for use with thenon-combustible aerosol provision device may comprise an aerosolizablematerial.

In some embodiments, the aerosol generating component is a heatercapable of interacting with the aerosolizable material so as to releaseone or more volatiles from the aerosolizable material to form anaerosol. In one embodiment, the aerosol generating component is capableof generating an aerosol from the aerosolizable material withoutheating. For example, the aerosol generating component may be capable ofgenerating an aerosol from the aerosolizable material without applyingheat thereto, for example via one or more of vibrational, mechanical,pressurization or electrostatic means.

In some embodiments, the aerosolizable material may comprise an activematerial, an aerosol forming material and optionally one or morefunctional materials. The active material may comprise nicotine(optionally contained in tobacco or a tobacco derivative) or one or moreother non-olfactory physiologically active materials. A non-olfactoryphysiologically active material is a material which is included in theaerosolizable material in order to achieve a physiological responseother than olfactory perception. The aerosol forming material maycomprise one or more of glycerine, glycerol, propylene glycol,diethylene glycol, triethylene glycol, tetraethylene glycol,1,3-butylene glycol, erythritol, meso-Erythritol, ethyl vanillate, ethyllaurate, a diethyl suberate, triethyl citrate, triacetin, a diacetinmixture, benzyl benzoate, benzyl phenyl acetate, tributyrin, laurylacetate, lauric acid, myristic acid, and propylene carbonate. The one ormore functional materials may comprise one or more of flavors, carriers,pH regulators, stabilizers, and/or antioxidants.

In some embodiments, the article for use with the non-combustibleaerosol provision device may comprise aerosolizable material or an areafor receiving aerosolizable material. In one embodiment, the article foruse with the non-combustible aerosol provision device may comprise amouthpiece. The area for receiving aerosolizable material may be astorage area for storing aerosolizable material. For example, thestorage area may be a reservoir. In one embodiment, the area forreceiving aerosolizable material may be separate from, or combined with,an aerosol generating area.

Alternatively or in addition to aerosol provision systems, a deliverydevice may include any device that causes/enables the introduction of anactive ingredient into the body of the user in a manner that allows theactive ingredient to take effect.

Example delivery devices may thus for example include a device thatdisperses an aerosol into a receptacle, after which a user may take thereceptacle from the device and inhale or sip the aerosol. Hence thedelivery device does not necessarily have to be directly engaged with bythe user at the point of consumption.

In this regard, a delivery device may alternatively or in additionprovide a reminder or usage regime for a user, for example reminding auser when to use a snus pouch, or other active deliverable such as apill. The delivery device may optionally store and dispense suchconsumables according to the reminder or usage regime.

Similarly, an example delivery device may be a home refill station,which mixes e-liquid components for the user and uses the mix to fill areservoir of their e-cigarette, thereby determining the type, blend,and/or concentration of active ingredients that the user will consume,all else being equal. Such a home refill station may be referred to as a‘dock’, as may a power recharging station, or a device that combinesboth functions.

In this regard, a delivery device operating as a vending machine maysimilarly provide consumable refills or disposable devices based onmixes and/or selections of e-liquid components, either mixed on demandor equivalently selected from a range of pre-prepared mixes. Similarly,in other implementations, the vending machine may dispense oral products(such as for example snus, snuff, gums, gels, sprays, and other deliverysystems such as patches) or other consumable products containing activeingredients and/or flavorants, for example.

In each case, the delivery device is operable to influence one or moreof the amount, timing, type, blend, and/or concentration of activeingredient consumed by the user.

Hence more generally a delivery device is operable to influence aproperty of an active ingredient consumed by a user.

It will be appreciated that several delivery devices may operate intandem to provide this influence. For example a home refill station, ora vending machine, may operate in conjunction with an e-cigarette toactually deliver a modification of active ingredient, or other feedback,to a user. Similarly a mobile phone may operate in parallel with ane-cigarette to provide information or analysis relevant to themodification or other feedback.

In this sense a delivery device may actually be a delivery systemcomprising multiple devices operating sequentially and/or in parallel toaffect the desired influence/feedback. Hence references to a deliverydevice or delivery system herein may be considered interchangeableexcept where stated otherwise.

Referring now to the drawings, wherein like reference numerals designateidentical or corresponding parts throughout the several views, FIG. 1 isa schematic diagram of a vapor/aerosol provision system such as ane-cigarette 10 (not to scale), providing a non-limiting example of adelivery device in accordance with some embodiments of the disclosure.

The e-cigarette has a generally cylindrical shape, extending along alongitudinal axis indicated by dashed line LA, and comprises two maincomponents, namely a body 20 and a cartomizer 30. The cartomizerincludes an internal chamber containing a reservoir of a payload such asfor example a liquid comprising nicotine, a vaporizer (such as aheater), and a mouthpiece 35. References to ‘nicotine’ hereafter will beunderstood to be merely an example and can be substituted with anysuitable active ingredient. References to ‘liquid’ as a payloadhereafter will be understood to be merely an example and can besubstituted with any suitable payload such as botanical matter (forexample tobacco that is to be heated rather than burned), or a gelcomprising an active ingredient and/or flavoring. The reservoir may be afoam matrix or any other structure for retaining the liquid until suchtime that it is required to be delivered to the vaporizer. In the caseof a liquid/flowing payload, the vaporizer is for vaporizing the liquid,and the cartomizer 30 may further include a wick or similar facility totransport a small amount of liquid from the reservoir to a vaporizinglocation on or adjacent the vaporizer. In the following, a heater isused as a specific example of a vaporizer. However, it will beappreciated that other forms of vaporizer (for example, those whichutilize ultrasonic waves) could also be used and it will also beappreciated that the type of vaporizer used may also depend on the typeof payload to be vaporized.

The body 20 includes a re-chargeable cell or battery to provide power tothe e-cigarette 10 and a circuit board for generally controlling thee-cigarette. When the heater receives power from the battery, ascontrolled by the circuit board, the heater vaporizes the liquid andthis vapor is then inhaled by a user through the mouthpiece 35. In somespecific embodiments the body is further provided with a manualactivation device 265, e.g. a button, switch, or touch sensor located onthe outside of the body.

The body 20 and cartomizer 30 may be detachable from one another byseparating in a direction parallel to the longitudinal axis LA, as shownin FIG. 1 , but are joined together when the device 10 is in use by aconnection, indicated schematically in FIG. 1 as 25A and 25B, to providemechanical and electrical connectivity between the body 20 and thecartomizer 30. The electrical connector 25B on the body 20 that is usedto connect to the cartomizer 30 also serves as a socket for connecting acharging device (not shown) when the body 20 is detached from thecartomizer 30. The other end of the charging device may be plugged intoa USB socket to re-charge the cell in the body 20 of the e-cigarette 10.In other implementations, a cable may be provided for direct connectionbetween the electrical connector 25B on the body 20 and a USB socket.

The e-cigarette 10 is provided with one or more holes (not shown in FIG.1 ) for air inlets. These holes connect to an air passage through thee-cigarette 10 to the mouthpiece 35. When a user inhales through themouthpiece 35, air is drawn into this air passage through the one ormore air inlet holes, which are suitably located on the outside of thee-cigarette. When the heater is activated to vaporize the nicotine fromthe cartridge, the airflow passes through, and combines with, thegenerated vapor, and this combination of airflow and generated vaporthen passes out of the mouthpiece 35 to be inhaled by a user. Except insingle-use devices, the cartomizer 30 may be detached from the body 20and disposed of when the supply of liquid is exhausted (and replacedwith another cartomizer if so desired).

It will be appreciated that the e-cigarette 10 shown in FIG. 1 ispresented by way of example, and various other implementations can beadopted. For example, in some embodiments, the cartomizer 30 is providedas two separable components, namely a cartridge comprising the liquidreservoir and mouthpiece (which can be replaced when the liquid from thereservoir is exhausted), and a vaporizer comprising a heater (which isgenerally retained). As another example, the charging facility mayconnect to an additional or alternative power source, such as a carcigarette lighter.

FIG. 2 is a schematic (simplified) diagram of the body 20 of thee-cigarette 10 of FIG. 1 in accordance with some embodiments of thedisclosure. FIG. 2 can generally be regarded as a cross-section in aplane through the longitudinal axis LA of the e-cigarette 10. Note thatvarious components and details of the body, e.g. such as wiring and morecomplex shaping, have been omitted from FIG. 2 for reasons of clarity.

The body 20 includes a battery or cell 210 for powering the e-cigarette10 in response to a user activation of the device. Additionally, thebody 20 includes a control unit (not shown in FIG. 2 ), for example achip such as an application specific integrated circuit (ASIC) ormicrocontroller, for controlling the e-cigarette 10. The microcontrolleror ASIC includes a CPU or micro-processor. The operations of the CPU andother electronic components are generally controlled at least in part bysoftware programs running on the CPU (or other component). Such softwareprograms may be stored in non-volatile memory, such as ROM, which can beintegrated into the microcontroller itself, or provided as a separatecomponent. The CPU may access the ROM to load and execute individualsoftware programs as and when required. The microcontroller alsocontains appropriate communications interfaces (and control software)for communicating as appropriate with other devices in the body 10.

The body 20 further includes a cap 225 to seal and protect the far(distal) end of the e-cigarette 10. Typically there is an air inlet holeprovided in or adjacent to the cap 225 to allow air to enter the body 20when a user inhales on the mouthpiece 35. The control unit or ASIC maybe positioned alongside or at one end of the battery 210. In someembodiments, the ASIC is attached to a sensor unit 215 to detect aninhalation on mouthpiece 35 (or alternatively the sensor unit 215 may beprovided on the ASIC itself). An air path is provided from the air inletthrough the e-cigarette, past the airflow sensor 215 and the heater (inthe vaporizer or cartomizer 30), to the mouthpiece 35. Thus when a userinhales on the mouthpiece of the e-cigarette, the CPU detects suchinhalation based on information from the airflow sensor 215.

At the opposite end of the body 20 from the cap 225 is the connector 25Bfor joining the body 20 to the cartomizer 30. The connector 25B providesmechanical and electrical connectivity between the body 20 and thecartomizer 30. The connector 25B includes a body connector 240, which ismetallic (silver-plated in some embodiments) to serve as one terminalfor electrical connection (positive or negative) to the cartomizer 30.The connector 25B further includes an electrical contact 250 to providea second terminal for electrical connection to the cartomizer 30 ofopposite polarity to the first terminal, namely body connector 240. Theelectrical contact 250 is mounted on a coil spring 255. When the body 20is attached to the cartomizer 30, the connector 25A on the cartomizer 30pushes against the electrical contact 250 in such a manner as tocompress the coil spring in an axial direction, i.e. in a directionparallel to (co-aligned with) the longitudinal axis LA. In view of theresilient nature of the spring 255, this compression biases the spring255 to expand, which has the effect of pushing the electrical contact250 firmly against connector 25A of the cartomizer 30, thereby helpingto ensure good electrical connectivity between the body 20 and thecartomizer 30. The body connector 240 and the electrical contact 250 areseparated by a trestle 260, which is made of a non-conductor (such asplastic) to provide good insulation between the two electricalterminals. The trestle 260 is shaped to assist with the mutualmechanical engagement of connectors 25A and 25B.

As mentioned above, a button 265, which represents a form of manualactivation device 265, may be located on the outer housing of the body20. The button 265 may be implemented using any appropriate mechanismwhich is operable to be manually activated by the user—for example, as amechanical button or switch, a capacitive or resistive touch sensor, andso on. It will also be appreciated that the manual activation device 265may be located on the outer housing of the cartomizer 30, rather thanthe outer housing of the body 20, in which case, the manual activationdevice 265 may be attached to the ASIC via the connections 25A, 25B. Thebutton 265 might also be located at the end of the body 20, in place of(or in addition to) cap 225.

FIG. 3 is a schematic diagram of the cartomizer 30 of the e-cigarette 10of FIG. 1 in accordance with some embodiments of the disclosure. FIG. 3can generally be regarded as a cross-section in a plane through thelongitudinal axis LA of the e-cigarette 10. Note that various componentsand details of the cartomizer 30, such as wiring and more complexshaping, have been omitted from FIG. 3 for reasons of clarity.

The cartomizer 30 includes an air passage 355 extending along thecentral (longitudinal) axis of the cartomizer 30 from the mouthpiece 35to the connector 25A for joining the cartomizer 30 to the body 20. Areservoir of liquid 360 is provided around the air passage 335. Thisreservoir 360 may be implemented, for example, by providing cotton orfoam soaked in liquid. The cartomizer 30 also includes a heater 365 forheating liquid from reservoir 360 to generate vapor to flow through airpassage 355 and out through mouthpiece 35 in response to a user inhalingon the e-cigarette 10. The heater 365 is powered through lines 366 and367, which are in turn connected to opposing polarities (positive andnegative, or vice versa) of the battery 210 of the main body 20 viaconnector 25A (the details of the wiring between the power lines 366 and367 and connector 25A are omitted from FIG. 3 ).

The connector 25A includes an inner electrode 375, which may besilver-plated or made of some other suitable metal or conductingmaterial. When the cartomizer 30 is connected to the body 20, the innerelectrode 375 contacts the electrical contact 250 of the body 20 toprovide a first electrical path between the cartomizer 30 and the body20. In particular, as the connectors 25A and 25B are engaged, the innerelectrode 375 pushes against the electrical contact 250 so as tocompress the coil spring 255, thereby helping to ensure good electricalcontact between the inner electrode 375 and the electrical contact 250.

The inner electrode 375 is surrounded by an insulating ring 372, whichmay be made of plastic, rubber, silicone, or any other suitablematerial. The insulating ring is surrounded by the cartomizer connector370, which may be silver-plated or made of some other suitable metal orconducting material. When the cartomizer 30 is connected to the body 20,the cartomizer connector 370 contacts the body connector 240 of the body20 to provide a second electrical path between the cartomizer 30 and thebody 20. In other words, the inner electrode 375 and the cartomizerconnector 370 serve as positive and negative terminals (or vice versa)for supplying power from the battery 210 in the body 20 to the heater365 in the cartomizer 30 via supply lines 366 and 367 as appropriate.

The cartomizer connector 370 is provided with two lugs or tabs 380A,380B, which extend in opposite directions away from the longitudinalaxis of the e-cigarette 10. These tabs are used to provide a bayonetfitting in conjunction with the body connector 240 for connecting thecartomizer 30 to the body 20. This bayonet fitting provides a secure androbust connection between the cartomizer 30 and the body 20, so that thecartomizer and body are held in a fixed position relative to oneanother, with minimal wobble or flexing, and the likelihood of anyaccidental disconnection is very small. At the same time, the bayonetfitting provides simple and rapid connection and disconnection by aninsertion followed by a rotation for connection, and a rotation (in thereverse direction) followed by withdrawal for disconnection. It will beappreciated that other embodiments may use a different form ofconnection between the body 20 and the cartomizer 30, such as a snap fitor a screw connection.

FIG. 4 is a schematic diagram of certain details of the connector 25B atthe end of the body 20 in accordance with some embodiments of thedisclosure (but omitting for clarity most of the internal structure ofthe connector as shown in FIG. 2 , such as trestle 260). In particular,FIG. 4 shows the external housing 201 of the body 20, which generallyhas the form of a cylindrical tube. This external housing 201 maycomprise, for example, an inner tube of metal with an outer covering ofpaper or similar. The external housing 201 may also comprise the manualactivation device 265 (not shown in FIG. 4 ) so that the manualactivation device 265 is easily accessible to the user.

The body connector 240 extends from this external housing 201 of thebody 20. The body connector 240 as shown in FIG. 4 comprises two mainportions, a shaft portion 241 in the shape of a hollow cylindrical tube,which is sized to fit just inside the external housing 201 of the body20, and a lip portion 242 which is directed in a radially outwarddirection, away from the main longitudinal axis (LA) of the e-cigarette.Surrounding the shaft portion 241 of the body connector 240, where theshaft portion does not overlap with the external housing 201, is acollar or sleeve 290, which is again in a shape of a cylindrical tube.The collar 290 is retained between the lip portion 242 of the bodyconnector 240 and the external housing 201 of the body, which togetherprevent movement of the collar 290 in an axial direction (i.e. parallelto axis LA). However, collar 290 is free to rotate around the shaftportion 241 (and hence also axis LA).

As mentioned above, the cap 225 is provided with an air inlet hole toallow air to flow when a user inhales on the mouthpiece 35. However, insome embodiments the majority of air that enters the device when a userinhales flows through collar 290 and body connector 240 as indicated bythe two arrows in FIG. 4 .

Referring now to FIG. 5 , the e-cigarette 10 (or more generally anydelivery device as described elsewhere herein) may operate within awider delivery ecosystem 1. Within the wider delivery ecosystem, anumber of devices may communicate with each other, either directly(shown with solid arrows) or indirectly (shown with dashed arrows).

In FIG. 5 , as an example delivery device an e-cigarette 10 maycommunicate directly with one or more other classes of device (forexample using Bluetooth® or Wifi Direct®), including but not limited toa smartphone 100, a dock 200 (e.g. a home refill and/or chargingstation), a vending machine 300, or a wearable 400. As noted above,these devices may cooperate in any suitable configuration to form adelivery system.

Alternatively or in addition the delivery device, such as for examplethe e-cigarette 10, may communicate indirectly with one or more of theseclasses of device via a network such as the internet 500, for exampleusing Wifi®, near field communication, a wired link or an integralmobile data scheme. Again, as noted above, in this manner these devicesmay cooperate in any suitable configuration to form a delivery system.

Alternatively or in addition the delivery device, such as for examplethe e-cigarette 10, may communicate indirectly with a server 1000 via anetwork such as the internet 500, either itself for example by usingWifi, or via another device in the delivery ecosystem, for example usingBluetooth® or Wifi Direct® to communicate with a smartphone 100, a dock200, a vending machine 300, or a wearable 400 that then communicateswith the server to either relay the e-cigarette's communications, orreport upon its communications with the e-cigarette 10. The smartphone,dock, or other device within the delivery ecosystem, such as a point ofsale system/vending machine, may hence optionally act as a hub for oneor more delivery devices that only have short range transmissioncapabilities. Such a hub may thus extend the battery life of a deliverydevice that does not need to maintain an ongoing WiFi® or mobile datalink. It will also be appreciated that different types of data may betransmitted with different levels of priority; for example data relatingto the user feedback system (such as user factor data or feedback actiondata, as discussed herein) may be transmitted with a higher prioritythan more general usage statistics, or similarly some user factor datarelating to more short-term variables (such as current physiologicaldata) may be transmitted with a higher priority than user factor datarelating to longer-term variables (such as current weather, or day ofthe week). A non-limiting example transmission scheme allowing higherand lower priority transmission is LoRaWAN.

Meanwhile, the other classes of device in the ecosystem such as thesmartphone, dock, vending machine (or any other point of sale system)and/or wearable may also communicate indirectly with the server 1000 viaa network such as the internet 500, either to fulfil an aspect of theirown functionality, or on behalf of the delivery system (for example as arelay or co-processing unit). These devices may also communicate witheach other, either directly or indirectly.

In an embodiment of the description, to form a user feedback system aswill be described later herein, the server 1000, the delivery device,such as for example the e-cigarette 10, and/or any other device withinthe delivery ecosystem, may utilize one or more sources of informationwithin the delivery ecosystem or accessible by one or more deviceswithin it in order to be more accurately responsive to the user's state.These may include a wearable or mobile phone (or any other source, suchas the dock or vending machine), or sources such as a storage system1012 of the server. The delivery device may also provide information(such as data relating to interaction with an e-cigarette) to one ormore data receivers within the ecosystem, which again may comprise oneor more of a wearable, mobile phone, dock, or vending machine, or theserver.

To form a user feedback system as will be described later herein, adevice within the delivery ecosystem, such as the delivery device 10,may utilize one or more processors to analyze or otherwise process thisinformation, in order to estimate the user's state and/or estimate aform of feedback action determined to alter the estimated state of auser (whether a typical/default user, or a user of a similar demographicto the current user, or specifically the current user), for example bycausing modification of one or more operations of the delivery device oranother device in the delivery ecosystem.

It will be appreciated that the delivery ecosystem may comprise multipledelivery devices (10), for example because the user owns multipledevices (for example so as to easily switch between different activeingredients or flavorings), or because multiple users share the samedelivery ecosystem, at least in part (for example cohabiting users mayshare a charging dock, but have their own phones or wearables).Optionally such devices may similarly communicate directly or indirectlywith each other, and/or with devices within the shared deliveryecosystem and/or the server. In such cases, a PIN, ID or account may beassociated with each delivery device, so that devices can be associatedwith the correct user, particularly where multiple users share the samedelivery ecosystem.

It will be appreciated that references to ‘the user's state’ encompassone of many states of the user, or equivalently one aspect of theoverall state of the user. Hence for example the user's level of stress,which as a non-limiting example may be a combination of socialcircumstance and cortisol levels, is an example of ‘the state of theuser’, but does not completely define the user. In other words, thestate of the user is a state relevant to the potential intervention ofone or more feedback actions as described elsewhere herein.

User Feedback System

Referring now to FIG. 6 , in an embodiment of the description, a userfeedback system 2 for a user of a delivery device within a deliveryecosystem 1 comprises an obtaining processor 1010 operable to obtain oneor more user factors indicative of user state, an estimation processor1020 operable to calculate an estimation of user state based upon one ormore of the obtained user factors, and a feedback processor 1030operable to select a feedback action for at least a first device withinthe delivery ecosystem, responsive to the estimation of user state, in amanner expected to alter the estimated state of a user.

FIG. 6 illustrates one possible embodiment of such a user feedbacksystem as a non-limiting example.

In this embodiment, the obtaining processor 1010, estimation processor1020, and feedback processor 1030 are located within the server 1000.However, it will be appreciated that any one or more of these processorsmay be located elsewhere within the ecosystem 1, or its role may beshared between two or more processors in server and/or the ecosystem.For example the obtaining processor may be located in an e-cigarette ormobile phone, or the feedback processor may be located in a vendingmachine or e-cigarette, or the functionality of these processes may beshared between the server and such devices. In other examples, theseprocessors may be local to the delivery device (e.g. an e-cigarette), orto a delivery system comprising the delivery device and a mobile phone.

Obtaining Processor

The obtaining processor 1010 obtains or receives one or more userfactors from one or more sources, with the user factors being in one ormore classes of data.

Such user factors may have a causal and/or correlating relationship withthe user's state, or some other predictable relationship with it. Whilstsuch a state may be associated with what is colloquially referred to asthe user's ‘mood’, the user's subjective mood per se is not a primaryconsideration of the feedback system; rather, the feedback systemrelates to the correspondence between obtained user factor(s) and userstates, and user states and a form of feedback action that may altersuch a state of the user, typically in a predetermined manner that isbeneficial to the user.

Further it will be appreciated that where there is a correspondencebetween user factor(s) and states, and states and feedback, there isalso in principle a correspondence between the user factor(s) and thefeedback, without the intervening state necessarily needing to beexplicitly estimated.

The classes of data obtained by or for the obtaining processor includebut are not limited to: indirect or historical data; neurological orphysiological data; contextual data; environmental or deterministicdata; and use-based data.

Indirect or Historical Data

Indirect or historical data provides background information about theuser that is not necessarily related to their immediate circumstances(e.g. not their immediate environment or context), but which maynevertheless have an influence on the user's state.

Examples of indirect or historical data include but are not limited tothe user's purchase history, previously input user preference data, orbehavioral patterns in general. Hence more generally, user choices oractions, typically relating to the delivery device but typically notdirectly derived from use of the delivery device itself.

Optionally, such information (or indeed any persistent information, suchas preferred user settings, or model data for user state and/or feedbackaction as described elsewhere herein, account details, or other storeduser factor data), can be transferred between devices where a given userpurchases or uses different delivery devices, so that such informationdoes not need to be re-acquired for new or respective devices. Suchinformation can be transferred or shared for example by direct datatransfer via Bluetooth® link between old and new devices. However, sincea potential reason for buying a new device is because a previous one hasbeen lost, alternatively or in addition the information may betransferred or shared by (also) holding the information remotely inassociation with an account/user ID to which different deliverydevices/systems of the user are then also associated. Hence a systemwith learnt/obtained indirect or historical data on an old device may betransferred or shared to a new device either directly between devices orvia a centralized user account.

As an example of historical information, purchase history may beindicative of a user's state, being indicative of a general state of theuser long term (for example in terms of significant or recurrentpurchases), and/or a recent state of the user (for example in terms ofrecent purchases, or purchases that are likely to still influence theuser).

Hence purchase history that may be indicative of the user's stateincludes type(s) of products bought, frequency of purchase, and the like(not necessarily limited to products directly related to the deliverydevice or its consumables), how they are bought (e.g., online vs shop),and volume of purchases in a time period or a single purchasing event.The correspondence between how purchases (and the purchased product orservice) affect a user's state can be initially determined on apopulation basis (e.g. to enable a statistically significant amount ofdata to be collated, for example via a questionnaire), or on a subset ofsuch a population having similar demographics to the user, and/or on thebasis of the individual user. Purchases may assist with this process forexample, by being marked as associated with certain states, whetherusing human readable (and subsequently entered e.g. on their phone bythe user) or machine readable markings (such as QR codes e.g. scanned bythe user with their phone); if a consumable or other purchase comprisesa machine readable mark, this may be registered as an indicator of mood.

Similarly, a consumable may comprise a means for it to be recognized asindicative of mood when inserted or otherwise loaded into the deliverydevice; for example a microchip with a code, or another uniquelyidentifiable means of electronically detecting a payload type (such as abinary pattern of conductive dots on the consumable's surface that maybe detected by corresponding contacts on the delivery device), may beused. Such identifiable types may vary by composition (e.g. flavors,active ingredients or concentrations of either) or defaultadministration (e.g. two types could be identical except for indicatingto the device a different heating profile that results in a differentinhalation effect).

The obtaining processor may obtain indirect or historical data from anumber of sources, including user profile data held in storage 1012 atthe server, for example comprising previously input user preferencedata, and/or similarly logs of interactions and/or usage patterns; webor Internet based data 110 such as purchasing records received fromvendors or other partners; information gathered with consent by a mobilephone 100 of the user, variously relating to input user preference data,on-line purchases, interaction/usage data (for example where the phoneoperates in tandem with an e-cigarette or other delivery device as adelivery system local to the user), user questionnaires, and the like.Similarly alternatively or in addition the obtaining processor mayobtain such data from the delivery device itself.

Neurological and/or Physiological Data

Neurological and/or physiological data is descriptive of the physicalstate of the user, in terms of mind and/or body. The data can bedescriptive of the user's state on various timescales, includingimmediate status or changes in state (such as for example heart rate),longer term status or changes in state (such as hormonal cycles), orchronic status, such as fitness levels.

Non-limiting examples of long-term data, for example in the order ofmultiple months to years, include indicators of the user's metabolism,body shape (e.g. ectomorph, mesomorph, endomorph) or body mass index;chronic disease; any other long term condition such as pregnancy; andactivity/fitness level.

Such data may be obtained by or for the obtaining processor from one ormore user questionnaires (for example either a questionnaire completedspecifically to assist the user feedback system, and/or a questionnairecompleted for any third-party partner, for example for a fitnesswearable device or social media provider); medical or insurance recordsby consent; or at least in part from other devices such as a fitnesswearable 400 and/or other devices in a wider ecosystem 1 such as smartscales. The optional timing of such questionnaires is describedelsewhere herein.

Non-limiting examples of medium-to-long-term data, for example in theorder of multiple weeks to months, include a user's hormonal levels orhormonal cycles for hormones such as estrogen, testosterone, dopamineand cortisol; any acute condition or illness; and activity/fitnesslevel.

Non-limiting examples of medium term data, for example in the ordermultiple days to weeks, include a user's sleep cycle; any acutecondition or illness; and a user's hormonal levels or hormonal cyclesfor hormones such as estrogen, testosterone, dopamine and cortisol.

Non-limiting examples of medium to short-term data, for example in theorder of multiple hours to days, include the user's degree ofwakefulness; their degree of activity; appetite or fullness; bloodpressure; temperature; and again any acute condition or illness, and/orhormones.

Again such medium term data (whether longer or shorter) may be obtainedby or for the obtaining processor from questionnaires, medical or otherrecords, or fitness or other smart devices. Hence for example hormonallevels may be obtained or inferred from questionnaires, medical or otherrecords, diary or calendar entries with consent, and/or fitness or othersmart devices, including for example pinprick blood tests. Similarlyblood pressure, temperature, degree of activity and the like can beobtained from smart devices (typically wearables) or user input.

Non-limiting examples of short term data, for example in the order ofmultiple minutes to hours, include the user's sweat response; galvanicskin response (phasic and/or tonic); their degree of activity; appetiteor fullness; blood pressure; breathing rate; temperature; muscletension; heart rate and/or heart rate variability; and again any acutecondition or illness, and/or hormones.

In addition, neurological and/or physiological information specific tothe delivery device may also be obtained by the obtaining processor,such as the cumulative amount of vapor generated within the short term(for example within a preceding period corresponding to one, two or moretimes the pharmacological half-life of the active ingredient in theuser's body).

Non-limiting examples of immediate data, for example in the order ofseconds to minutes, include the user's body position; blink rate;breathing rate; heart rate; heart rate variability; brain wave pattern;galvanic skin response (e.g. phasic); muscle tension; skin temperature;voice (e.g. qualities such as volume, pitch, breathiness); and theirdegree of activity.

Again short-term and immediate data may be obtained by or for theobtaining processor typically from biometric sensing, for example usingsmart devices, or using any suitable approach described herein. Forexample galvanic skin response could be measured by electrodes on thedelivery device; heart rate can be obtained by optical scanning of ablood vessel on the wrist by a wearable device, or by use of anelectrocardiogram (ECG) or other dedicated strap-on device. Similarlybrainwave patterns can be detected by an electroencephalogram (EEG), andmuscle tension can be detected by electromyogram (EMG). Meanwhile bodyposition, blinking and the like can be captured for example by a cameraon a phone or in a vending machine.

It may be that short term and immediate physiological data are difficultto obtain; for example a smartwatch may only check the user's heart rateevery 10 minutes, meaning that for a given puff the available data istoo old to have direct relevance. Similarly a user may wear gloves,making galvanic skin response unavailable. Other data may require theuser's chose to wear an appropriate sensor, which they may not doconsistently. Similarly, some short term and immediate data may indicatevalues that have multiple causes, and hence may indicate multiple statesof the user. For example an elevated heart rate may suggest that theuser is stressed, or may indicate that the user is enjoying exercise.Consequently it may be that optionally such short term and immediatephysiological data is only used in conjunction with other contextualdata that serves to disambiguate the readings. For example, an elevatedheart rate during office hours, where the user is located at work and isnot travelling a significant distance is much more likely to be a signof stress than the same hear rate on a Saturday morning when the user isdetected as travelling at a running pace near their home.

Hence short term and immediate physiological data (and as appropriateany neurological or physiological data that may require contextualdisambiguation) may be discounted, or have a reduced weighting, in theobtaining and packaging of data and/or the evaluation of the user'sstate, or optionally may be used or more fully weighted whendisambiguating contextual data is also obtained that indicates the typeof state that the data is likely to relate to.

To the extent that the same examples span different time frames in theabove description, it will be appreciated for example that differenthormones, hormonal cycles, fitness levels and the like can have shorterand longer term characteristics. It will also be appreciated that wherean example of data is included in one list but not another, this doesnot preclude the data being gathered/used over a different time frame;for example blood pressure may be listed as an example of short termdata, but clearly may also be part of longer term data, for example dueto ongoing high blood pressure.

As with indirect or historical data, data of a plurality of these typesand/or from multiple sources may be used in any suitable combination.

In addition to directly measured neurological or physiological data, anysuitable analysis or data fusion may be implemented to obtain data ofparticular relevance to the delivery device regarding the user's state.

For example, the feedback system may be operable to estimate a currentnicotine concentration (as a non-limiting example of an activeingredient), or a concentration of active or inactive compounds thatbreak down from the consumed ingredient, within a user (and subsequentlydeliver nicotine/the active ingredient accordingly).

Hence in principle the feedback system (for example in a pre-processoror subsystem of the obtaining processor) may estimate the concentrationof nicotine in the user based on monitoring the nicotine consumed, thetime at which it is consumed, and having stored the value for thehalf-life of nicotine in the body (around 2 hours, although this valuecan be refined based on information regarding the individual, such asheight, weight etc.). Such monitoring can be performed based on usagedata from the delivery device. Hence for example based on the originalactive ingredient concentration, and a predetermined relationshipbetween heating/aerosol generator power and aerosol mass output, an massof active ingredient per unit volume inhaled may be estimated; fromthat, using predetermined absorption relationships (optionally based onanalysis of depth/duration of inhalation, using airflow data), theamount of active absorbed may be determined; finally the body mass ofthe user, and potentially other factors such as a age, gender and thelike may be used to determine the concentration of active ingredientand/or breakdown products in the user over time. Again, here nicotine isa non-limiting example of an active ingredient.

It has been found that users typically try to have a nicotine levelwhich is between an upper and lower threshold (which may be differentbetween users), which collectively may be regarded as defining a‘baseline’ level. The feedback system can establish such a baseline(e.g., by monitoring use over time), and, as will be described in moredetail later herein, the feedback system can select and optionally causemodification of one or more operations of the delivery device to delivernicotine to match the baseline. The baseline may be a steady value ormay vary, e.g. with time of day or day of week. It may be initiallyestimated based on a profile of the user obtained for example from aquestionnaire, and/or built up or refined by information (measuredand/or self-reported) from the user.

Such a modification may be expected to alter the estimated state of auser, in a positive manner, as it has been previously determined thatthe chance that a user will be in a positive mood increases when theirnicotine levels are close to their personal baseline or thresholdedrange.

Where a user consumes several different active ingredients, each mayhave its own baseline thresholds. Optionally, the feedback system canmonitor whether consumption of one active ingredient overlaps another tothe extent that one active ingredient may affect the baseline ofanother, and if so modify these accordingly, for example based on storedpharmokinetic data relating to such overlaps.

As noted previously, in these circumstances it is likely that the userinteracts with multiple delivery devices to consume the different activeingredients, and the usage from each device may be combined for theassociated user. Alternatively, where a single device can switch betweenpayloads (for example hating different gels), or has a mixed payload ofactives, the currently heated payload or payload mix can be communicatedto the feedback system for the purposes of tracking consumption.

Contextual Data

Contextual data relates to situational factors other than environmentalfactors (see elsewhere herein) that may affect the user's state.Typically such situational factors affect the user's psychological stateor disposition towards stress, calm, happiness, sadness, or certainpatterns of behavior, and hence may also influence and/or have acorrelation with neurological and physiological user factors such asdopamine or cortisone levels, blood pressure, heart rate and the like asdescribed elsewhere herein.

Examples of contextual data include the user's culture, including at abroad scale where they live, their religion if they have one, and at anarrower scale their job and/or employment status, educationalattainment and the like, and social economic factors that may interactwith these such as gender and relationship status.

Such information may be obtained by or for the obtaining processor fromuser questionnaires, social media data, and the like. The optionaltiming of such questionnaires is described elsewhere herein.

Other contexts include the season (e.g. winter, spring, summer, autumn)or month, and any particular events or periods within that season ormonth, such as Lent, Easter, Ramadan, Christmas and the like. Forexample, users are more likely to see consumption at or below theirpersonal baseline as a positive thing during Lent, or the first fewweeks of January.

Such information may be obtained by or for the obtaining processor froma calendar and database of events, suitably filtered if appropriateaccording to other contexts such as country, religion, employment,gender and the like as described previously.

Other contexts include the user's agenda or calendar, which can indicatesources of stress or relaxation, and how busy or otherwise the user isat a given time. Hence for example a social event may be associated witha positive influence on user state, for example raising dopamine levels,whereas a medical appointment or driving test may be associated withstressors such as an increase in cortisol and heart rate. Similarlyevents, appointments, and/or reminders in rapid succession may indicatea negative effect on the user's state. The nature of events in theuser's agenda or calendar may be determined by keyword analysis asdescribed elsewhere herein, and the frequency or other metricsassociated with the calendar, such as the number of clashes, or theindividuals likely to attend a meeting, may be determined from the dataprovided by the calendar itself.

The user's agenda or calendar can also provide an indication of theuser's likely location, which may affect either their state, or theirability to use the delivery device in a manner that may modify thatstate. For example, the user may have different typical states, anddifferent abilities to use their delivery device, depending on whetherthey are at home, at work, in outdoor or indoor public spaces, in anurban or countryside environment, or commuting.

The relationship between user state and location may at least initiallybe based on data from a corpus of users. Alternatively or in additionthis relationship may be built up or refined based on data from the user(e.g. measured or self-reported), so that the user feedback systemlearns what the user is likely state will be at a given location,whether or not this is explicitly commented upon by the user.

It will be appreciated that the user's location may be determined from aGPS signal obtained by the delivery device or an associated device suchas a smartphone, or the registered location of a vending machine orpoint of sale unit. Optionally, a device such as the user's mobile phonemay comprise an off-line map or location database, for example recordinglocation of the user's home and work, and optionally the location ofdevices that may temporarily be incorporated into the users deliveryecosystem such as vending machines, public charging units and the like.This enables the device to compare the user's current location withlocations that may not be public knowledge (in the case of the user'spersonal details) or otherwise known to the user (in the case ofadditional delivery ecosystem infrastructure). If on the other hand theuser's location is fed back to a back end server for any reason (forexample as part of obtaining, combining or packaging data, user stateestimation, or feedback processing), then optionally the user's actuallocation could be partially obscured (i.e. made partly anonymous) byclassifying the location, e.g. as ‘Work’, ‘Home’, ‘Gym’, ‘Commuting’, orother classes of location, or ‘Other’ for unknowns. These could be doneon the user's phone, for example with a predetermined tolerance around aclassified GPS position being associated with the classification.

Alternatively or in addition the wireless environment can be associatedwith the location; for example an in-car Bluetooth, or on-train wifi maybe associated with ‘commuting’, whilst home, office or gym wifis may beassociated with those locations.

Whilst the user may be asked to identify/classify theselocations/wireless environments on their phone, optionally the GPS orwireless data may be sent to a secure server for automaticclassification by comparison to a database of locations and/or wirelessaccess points, for example managed by a third party.

In any event subsequently the classification of the location, ratherthan the location itself, may thus be provided by or for the obtainingprocessor.

With regards to commuting or other modes of travel, the type of travelmay influence the user's state. For example, walking may have a morepositive effect on the user's state than driving, for example in termsof heart rate, blood pressure and the like. More generally, activitylevels may influence the user's state, with increased activity generallyhaving a positive impact on the user, typically during the activity butpotentially also for the rest of that day and possibly the day after. Itwill be appreciated that this context illustrates the potential for thecombination of contexts to be significant, as walking in the sun versuswalking in the rain may have different effects on the user's state. Thetype of travel may for example be inferred from GPS data from the user'sphone, or the pairing of the phone or delivery device with a vehicle, orthe purchase of public transport tickets, or a questionnaire indicatingtravel habits/times.

Such information may be obtained by or for the obtaining processor fromwork or personal digital calendars, for example on the user's phone. Itwill also be appreciated that the user's phone, or other smart wearable,may directly provide an indication of the user's location, and/orhistorical patterns of location, for example corresponding to a user'shome and work locations and average commuting times.

Other contexts include the weather in the user's location or theupcoming weather in the user's location or upcoming location. Dependingon the user, sunny weather is likely to improve the user's mood andsociability, whilst poor weather is likely to lower the user's mood andpotentially reduce their sociability or affect their ability tosocialize. For example, some users are likely to behave so as to consumeactive ingredients to an extent that reflects their expectations of moodas suggested by the weather, optionally in conjunction with othercontextual factors and further user factors as described herein.

Such information may be obtained by or for the obtaining processor froma weather app, which may be located on a smart phone 100 of the user, oraccessed directly for example by the server 1000. More generally weatherdata may be obtained in response to GPS data (for example by thesmartphone) or locations indicated in the users calendar/appointments,and/or using a local weather measuring sensor such as a barometer.

Other contexts include the user's proximity to other people, eithergenerally in terms of crowds or social setting, or specifically in termsof other individuals with which there is in principle a measurablecorrelation with user behavior. For example, a user may have a differentstate depending on whether they are in proximity to their boss, theirwork colleagues, the friends, their partner, their children, or theirparents. Hence for example the user may have a different state in acrowded or sociable environment versus when alone or with a partner orfamily members. Or may behave differently when in the presence ofchildren than in the presence of only adults.

Such proximity can be inferred from the user's agenda or calendar, theirmobile phone, their delivery device, or their location. The user mayself-report their social status either specifically for the purpose ofthe user feedback system herein, or generally for example on socialmedia; meanwhile a phone and/or delivery device for example may detectsignals from other phones and/or delivery devices for more than apredetermined period of time, indicating they are remaining in eachother's presence. Optionally a phone's camera may be used to detectothers, but this may not be available if the phone is in a pocket orbag. The feedback system can also determine the proximity of users ofthe delivery device with other users of such a delivery device—e.g. anysuitable delivery device whose location can be determined by thefeedback system (for example directly or via an associated mobilephone), whether or not that other delivery device is part of a feedbacksystem itself. Similarly the feedback system can determine the proximityof specific people whom the user has, with permission, identified to thefeedback system; for example by providing their phone number to thefeedback system, or the system associating a detected Bluetooth® orother ID with that user.

A user may also indicate (for example via a questionnaire) their typicalstate in response to different social situations, groups or individuals,whether at a broad level such as ‘introverted’ or ‘extroverted’, or morespecifically.

Other contextual information relating to the user's social situation canbe measured directly using sensors such as microphones or cameras.

For example a microphone in the delivery device, the user's mobilephone, or any other device in the delivery ecosystem or connectablethereto to may be used to detect the user's voice (for example whenspeaking specifically to the device, or to other people nearby, on aphone call, or optionally as an ongoing background activity in a mannersimilar to a voice activated personal digital assistant). Properties ofthe user's voice such as volume, word speed, timbre, tonality, pitch,and/or non-harmonic content may be analyzed to determine whether theuser is vocalizing in a calm or a stressed manner, optionally aftercalibration for example to the user's neutral voice. Similarlyoptionally such a device in the delivery ecosystem may monitor forkeywords indicative of different states of the user, whether positiveand/or negative.

Such a microphone can also be used to detect background noise/music; ahigh degree of random or non-music noise may be indicative of astressful situation such as commuting, whilst a quiet background may beindicative of a calm situation such as being at home or in the garden.Similarly the type of music being listened to, whether specificallyidentified using known techniques, or analyzed to determine the presenceof a beat and any tempo may be indicative of the user's state, withspecific tracks related to positive or negative emotions beingindicative of corresponding emotional state of the user, whilst forexample upbeat dance music may be indicative of high dopamine levels,but slow music or music in a minor key may be indicative of a low moodor depression.

Like any other since a function described herein, where the appropriatesensor (in this case a microphone) is already present to provide otheranalyses, this additional facility could be provided by updating thesoftware of the relevant device or devices.

Similarly a device in the delivery ecosystem or connectable thereto maycomprise a camera. Data from images from such cameras can be obtainedpertaining to the user's state, including for example the user's overallfacial expression, which typically has a strong correlation with theuser's subjective mood, but also as described previously herein todetect when the user is alone or in a crowd, or with specificindividuals who may have a strong correlation with the user's state.

It will be appreciated that alternatively or in addition such a cameramay be used for other types of data, such as physiological data asdescribed previously herein. For example, muscle tension may bedetectable in the face, which tends to correlate with stress, strain, orpain. Meanwhile eye movements can indicate a user's degree of focusand/or the nature of some activities the user is undertaking (forexample patterns of eye movement and/or blinking will be different whendriving, reading, or socializing, and tend to differ when a person isalert or drowsy). Similarly, if capable of being resolved by the camera,micro-movements in the face or neck can be indicative of heart rate.

It will be appreciated that other contexts exist that may influence theuser's state, such as recently consumed information; social mediacontent, websites, internet searches, on-line adverts, news articles,streamed video, e-books, e-magazines, photos, music and other similarcontent that may be obtained by or for the obtaining processor. Somecontent may be assumed to have a universally consistent effect on thestate of users, such as for example news of a natural disaster, whilstother content may affect individuals differently, such as the resultsfor a user's preferred sports team, and be assessed individually, forexample based upon results of a user questionnaire.

The content of the consumed information may be assessed, for example forkeywords, to generate a rating for positive or negative influence on theuser's state. Optionally only the rating may be obtained by or for theobtaining processor, or any suitable digest, such as a keywordselection. More generally the obtaining processor may only receive adigest of user factors as appropriate, particularly where the sourcematerial does not itself enumerate some user factor property.

The obtaining processor, or a processor administering content such asthat described above, may perform such assessments. In the latter case,the processor may then provide its results either directly to theobtaining processor, or to the device within the delivery ecosystemthrough which the content is consumed, from which may subsequently berelayed to the obtaining processor, optionally after further processingfor example to incorporate one or more other metrics measured within thedelivery ecosystem.

By way of a concrete example, when a user consumes social media forexample via their mobile phone, then the social media platform, themobile phone or other consuming device, and/or the obtaining processor(whether operating separate to the mobile phone, or at least partiallyimplemented on the mobile phone or other consuming device) mayoptionally analyze the text of posts read by the user, and in particularoptionally analyze the texts of posts written by the user, for keywords.Some keywords may only be indirectly indicative of a user state; forexample, a user's choice of adjective or verb in a sentence may indicatewhether the user is feeling positive or negative, or calm or stressed.Similarly the presence of swearing can indicate stress. Meanwhilekeywords may explicitly indicate user state such as for example‘feel[ing] . . . nervous [about the trip to the] dentist’. In this case,the word ‘feel’ indicates the user is talking about themselves, and thekeywords ‘nervous’ and ‘dentist’ may be part of a predetermined set ofkeywords having a typically negative connotation or a determinablecorrelation or correspondence with levels of stress. The analysis of auser's consumed or produced social communications may optionally analyzeone or more of a user's choice of words, swearing, or explicitindications, as described above.

It will also be appreciated that alternatively or in addition to socialmedia use, optionally the above approach may be applied to user's texts,and/or calendar entries, and in conjunction with speech recognition,their phone conversations or real-world conversations with others.

A similar approach may be applied to news articles, e-books, e-magazinesand the like, and meta data associated with streamed video, photosand/or music.

Hence for example, whilst as noted previously herein a microphone may beused to assess the background noise or music around the user, where bycontrast the user is choosing the music, or specifically listening tomusic, meta data related to the music may be obtained including one ormore of artist, title, genre, and lyrics. Any of these may be assessedfor an indication of corresponding user state, for example based upon adatabase maintained by the server, or similar heuristics to thosedescribed above in relation to use of a microphone, but based uponsupplied metadata.

In a similar manner to assessing music, other content may be evaluatedin a similar way, such as websites; some websites are provided toentertain, while others are intended to inform and hence may becategorized according to genres or more generally classifications havinga correlation or correspondence with different user states. As notedelsewhere herein, the content of the websites may similarly be parsedfor keywords.

Likewise, usage of devices other than the delivery device may influencethe user's state. In particular a choice of apps on the user's phone,and the interaction, type of interaction, and/or duration of interactionwith them may have correlations with the user's state; for examplesocial media or playing a gaming app may raise dopamine and/or cortisollevels, heart rate, and the like; whilst listening to a music app mayalter heart rate and/or cortisol levels. The duration of interaction mayhave a linear or non-linear relationship with these changes of state, ormay with time indicate a different state; for example playing a game fora long time may indicate boredom.

It will be appreciated that for many user factors, not merely contextualbut of other types as well, a situational response (e.g. an expectedstate) may at least be initially based upon data from a cohort of users(for example a prior test population of users), but alternatively or inaddition may be built up or refined from information obtained from theuser (whether measured, received or self-reported).

Environmental and Deterministic Data

Environmental and deterministic data effectively relate to long-termcontext data outside of the user's choice or influence. There is someoverlap with longer term contextual influences such as culture; hencefor example the user's upbringing, their genetics, gender, biomeinternally (for example they gut biome) and/or externally (for examplewhether they live in an arid or verdant environment), and age.

As with other data described herein, such environmental anddeterministic data may be obtained by or for the obtaining processorfrom one or more user questionnaires (for example either a questionnairecompleted specifically to assist the user feedback system, and/or aquestionnaire completed for any third-party partner, for example for afitness wearable device or social media provider). Amongst other things,such a questionnaire may ask for details such as sex/gender, height,weight, ethnicity, age, etc. Such a questionnaire may also comprisepsychometric test questions to estimate a user's mental predispositionand/or history (e.g. one or more of extrovert/introvert, active/passive,optimist/pessimist, calm/anxious, independent/dependent,content/depressed, and the like). Such a questionnaire may also askquestions related to the user's culture and beliefs (e.g. one or moreof: a country of own or parent's origin; religion, if any; politicalpersuasion, if any; newspapers or news websites read, if any; othermedia consumption, if any; and the like). Again as with other datadescribed herein, some such environmental and deterministic data may beobtained by or for the obtaining processor from medical or insurancerecords by consent; and/or may be inferred from the user's location, asappropriate. The optional timing of such questionnaires is describedelsewhere herein.

Not all environmental and deterministic data need be long-term; hencefor example the time of day, day of the week and month of the year maybe considered environmental and deterministic data. Hence for examplethe user state may vary over the course of a day or week, for examplebeing different during weekdays and weekends, and/or during work hoursof the weekday versus evenings, and also potentially at specific timesof day. Similarly there may also be overlap for example with othercontextual data, such as the weather. Again there may also be synergybetween different user factors; for example the time of year may affectthe amount of daylight (in terms of both the length and potentially alsoweather patterns). The level and/or duration of daylight, either asmeasured (e.g. using a light sensor/camera on a device within thedelivery ecosystem) or as inferred from the date, may also have adetectable relationship with the user's state. The quality of light(e.g. color temperature, indoor/flickering or outdoor) may also betreated as such a user factor, for example captured by a camera withinthe delivery ecosystem.

It will be appreciated that the time of day, day of week and month ofyear may also be considered contextual data, particularly when definedfunctionally as work hours or a work routine, commuting time, personaltime, quality time etc., or where patterns of behavior over the courseof days, weeks, or months is established. These relates to changes inuser factor data as a function of day, week, or month, or therelationships between such user factor data and user state or identifiedfeedback actions. Hence as described elsewhere herein, one or twooperation models relating user factor data to feedback actions may usetime as an input or use different models and different times.

Use-Based Data

Use-based data relates to direct interactions of the user with thedelivery device and/or optionally any other device within the deliveryecosystem or which can report on interactions with it to the feedbacksystem (e.g. to the obtaining processor). These interactions may relateto vaping/consumption and/or manipulation/handling and/or setting thedevice.

Vaping/consumption based interactions may relate to the number,frequency, and/or distribution/pattern of puffs/acts of consumptionwithin one or more chosen periods. Such periods may include daily,hourly, as a function of location, as a function of pharmokinesis (forexample the active ingredient half-life within the body for one or moredelivered active ingredients), or any other period that may be relevantto the user's state, and/or chosen to increase the apparent correlationbetween number, frequency and/or distribution/pattern ofpuff/consumption and a user's state. Hence as a non-limiting example thetotal number of puffs in the device lifetime, since a payload/consumablerefill, in a month/week/day/hour, and/or in a particular session, andone or more corresponding cumulative usage times, may be included asmetadata with any puff data used in analysis either by the deliverydevice, a companion device such as a smartphone, and/or a remote server.Such puff data or puff metadata may also be associated with a timestamp, for example so that such a collation of puff data can beperformed subsequently, e.g. at the phone or remote server, and/or witha time stamp and/or associative link with another piece of (non-puff)data as described elsewhere herein.

Vaping based interactions may also relate to individual vaping actionsor statistical descriptions of a cohort thereof (for example but notlimited to a cohort within one of the above-described chosen periods),such as duration, volume, average airflow, airflow profile, activeingredient ratio, heater temperature, and the like.

Data relating to vapes and vaping behavior (or more generallyconsumption) as described above may be obtained by or for the obtainingprocessor from a delivery device itself, for example via a Wi-Fi®connection to the server 1000, or via communication with a companionmobile phone 100 or other local computing device, paired to the deliverydevice 10 for example via a Bluetooth® connection to form a deliverysystem.

The delivery device may comprise one or more airflow sensors asdescribed previously herein to determine when the user vapes and/or howthe user vapes, for example as characterized above, and raw datarelating to vaping/consumption events may be stored in the memory of thedelivery device or transmitted to the companion mobile phone. The datamay then be used to determine features such as the number, frequency,and/or distribution/pattern of puffs/acts of consumption within one ormore chosen periods, and/or the duration, volume, average airflow,airflow profile, average ingredient ratio, heater temperature values forone or more vaping/consumption events, using a processor of the deliverydevice and/or the mobile phone.

Optionally at least one sensor may be adapted to sense at least two ofpuff profile, puff frequency, puff duration, number of puffs, sessionlength, peak puff pressure and determine the mood of the user from thesensed information.

A user's puffing behavior provides a useful indicator of stress vsnon-stressed states. In particular, the intensity and frequency of auser's puff has been found to change from a normal level duringinstances of stress (e.g. to stronger and shorter puffs, and morefrequent puffs). Therefore optionally the delivery device or anotherdevice within the delivery ecosystem (such as the user's mobile phone)or a back end server may establish baseline profiles, frequencies,patterns, puff numbers, peak pressures and the like as describedelsewhere herein, and subsequently detect deviations from this baseline(e.g. above a predetermined threshold) indicative of stress. Furtheroptionally different baselines may be set for different situations andcontexts, such as time of day, day of week, and location; for example auser might be more stressed at work than at home, but this partialelevation of stress may be considered a baseline for a work context, andonly further stress might be considered to be a deviation that indicatesa change of user stress that may prompt a response.

Puff profile, for example, characterizes the variation of inhalationstrength over the duration of an inhalation. Hence for example theairflow rate of a puff may be used to characterize the puff profile,with higher airflow rates associated with short sharp inhalations beinglikely indicative of high stress than lower airflow rates. Pufffrequency may similarly have a correlation with stress such that instressed conditions the puff frequency may be higher than when the useris calm. Puff duration may be considered a subset of puff profile; to afirst approximation, the duration is also indicative of the type ofinhalation being taken, typically with a correlation between shorterpuffs in stressful situations and longer puffs with the user is calm.Peak puff pressure may also be considered a subset of puff profile, andis indicative of how sharply user inhales.

The number of puffs within a session can also be indicative of theuser's state. A session can be understood to either be a fixed period oftime, or defined functionally as a period comprising inhalations thatare separated by less than a predetermined period of time that is takento indicate that the session is over. for any given session, all elsebeing equal the number of puffs taken by a user is likely to be greaterwhen the user is in the stressed state than when the user is calm.Similarly, where a session is defined functionally, sessions are likelyto be shorter when the user is in a stressed state than when the user iscalm.

In any event as noted above, such information may then be packaged andsent to the obtaining processor as one or more user factors.

Manipulation/handling based interactions may relate to how the userinteracts with the delivery device when not actively vaping on it; forexample to characterize whether the delivery device is kept in a baguntil immediately prior to use, or whether the user plays or fidgetswith the delivery device in between uses.

Hence for example the delivery device or any other handheld devicewithin the delivery ecosystem, such as the user's mobile phone maycomprise a sensor for detecting handshake; that is to say, smallinvoluntary movements (so-called micro-movements) of the user's hand,such as trembling. Such micro-movements may be indicative of a state ofthe user. For example the amount, frequency, or prevalence of suchmicro-movements, and/or the amplitude of such micro-movements, arelikely to have a correlation or correspondence with one or more of userstress, adrenaline, autonomic nervous system function, user fatigue,user focus, and a user's deviation from a preferred baseline amount ofactive ingredient within their body.

In particular, micro-movements or tremors in the range 1-15 Hertz, ormore preferably 2-11 Hz or still more preferably 3 to 9 Hz areconsidered indicative of elevated stress or arousal, and so detection ofsuch motion may be used as an input indicative of stress. Conversely,optionally manipulations that are e.g. lower frequency may be consideredindicative of lower stress. Similarly movements that are not ‘micro’movements (i.e. deliberately swinging the device, as opposed to holdingit in a trembling hand) may either be ignored for the above purposes, oranalyzed for other significance (e.g. a motion characteristic ofimminent use, or associated with a wider context for which a user statehas a clear correlation).

Hence in some implementations, a user feedback system for a user of adelivery device within a delivery ecosystem may include: an obtainingprocessor adapted to obtain one or more user factors indicative of astate of the user, the one or more factors including the output from amotion sensor configured to detect micromovements or tremors of a user;an estimation processor adapted to calculate an estimation of user statebased upon one or more of the obtained user factors including at leastthe output from the motion sensor; and a feedback processor adapted toselect a feedback action for at least a first device within the deliveryecosystem, responsive to the estimation of user state, expected to alterthe estimated state of a user. In some implementations, the obtainingprocessor obtains only the output of the motion sensor as the one ormore user factors, and the estimation processor calculates an estimationof the user's state based only on the output of the motion sensor. Insome implementations, the motion sensor is provided in or on an aerosolprovision device of the delivery ecosystem. In some implementations, thefeedback action includes altering the operation of an aerosol provisiondevice.

Also for example, separate to micro-motions, a given user tends to holdtheir delivery device more often and/or for longer in times of stressthan when relaxed or in a calm scenario. This may be because the userhas made a conscious or unconscious link between the device and areduction in stress caused by vaping with it. Such holding may bedetected using one or more accelerometers and/or touch sensors asmentioned elsewhere herein.

Optionally the delivery device or another device within the deliveryecosystem (such as the user's mobile phone) or a back end server mayestablish baseline levels of holding and/or physical interaction withthe delivery device for the purpose of detecting when increased holdingand/or physical interaction occur (e.g. above a predeterminedthreshold), and similarly optionally may correlate such normal orelevated levels with other indicators or correlates of the user's stateand/or with the user's state directly so that holding and/or physicalinteraction can provide a (further) indication of user state and/or actas a proxy for another source of such indications if this is normallyused/preferred but currently unavailable. As with puffing behavior,Further optionally different baselines may be set for differentsituations and contexts, such as time of day, day of week, and location;for example a user might be more stressed at work than at home, but thispartial elevation of stress may be considered a baseline for a workcontext, and only further stress might be considered to be a deviationthat indicates a change of user stress that may prompt a response.

Hence in some implementations, a user feedback system for a user of adelivery device within a delivery ecosystem includes: an obtainingprocessor adapted to obtain one or more user factors indicative of astate of the user, the one or more factors including the output from oneor more sensors configured to detect when and/or how a user is holding adevice of the delivery ecosystem; an estimation processor adapted tocalculate an estimation of user state based upon one or more of theobtained user factors including at least the output from the one or moresensors; and a feedback processor adapted to select a feedback actionfor at least a first device within the delivery ecosystem, responsive tothe estimation of user state, expected to alter the estimated state of auser. In some implementations, the In some implementations, theobtaining processor obtains only the output of the one or more sensor asthe one or more user factors, and the estimation processor calculates anestimation of the user's state based only on the output of the one ormore sensors. In some implementations, the one or more sensors areprovided in or on an aerosol provision device of the delivery ecosystem.In some implementations, the feedback action includes altering theoperation of an aerosol provision device.

More generally in some implementations, for a user feedback system theone or more user factors include one or more user factors selected fromthe group comprising: one or more user inhalation characteristics,output from one or more motion sensors configured to detectmicromovements or tremors of a user, and the output from one or moresensors configured to detect when and/or how a user is holding a deviceof the delivery ecosystem; the inventors appreciate that a strongcorrelation exists between the data obtained from these user factors andthe determination of a user being in a stressed state.

The delivery device may comprise one or more touch by sensors or motionsensors (e.g accelerometers) to determine such interactions. Similarly,the device may comprise buttons and other settings for which userinteractions may be logged. Interactions with buttons and other settingsrelating to the delivery device on a companion mobile phone may also belogged. Such interaction data may then be packaged and sent to theobtaining processor is one or more user factors.

Hence for example using telemetry from one or more such motion sensorswithin the delivery device, the user feedback system can detectincidental or subconscious manipulation of the device based oncharacteristic changes in orientation, such as spins, flips, rocking andthe like, which are not related to gross movement of the device or theuser. Such toying may be indicative of a state of the user; for exampleit may be indicative of at least a subconscious wish to use the device,or to use the device more than is currently the case, and hencecorrelate with heightened stress, a lack of focus, and/or a user'sdeviation from a preferred baseline amount of active ingredient withintheir body.

Similarly for example, in a delivery device where activation uses abutton press or other UI interface, the delivery device may measure thetime between such activation and inhalation occurring. This period oftime is likely to have a correlation or correspondence with one or moreof user stress, user fatigue, user focus, and a user's deviation from apreferred baseline amount of active ingredient within their body. Hencefor example the period of time is likely to be shorter if the user isstressed than if the user is calm.

The delivery device or other devices within the delivery ecosystem maycomprise other sensors operable to obtain measurements relating to usageof behavior, including a microphone or a camera. These may recordinhalation and/or exhalation, relative timings and characters behaviorsrelated to inhalation actions or other behaviors and usages, which canbe determined from audio and/or image analysis as inputs to theobtaining processor.

It will be appreciated that where a user has multiple delivery devices10, usage may be aggregated across these devices, either by obtaininguser factor date from each device, or already aggregated via anintermediary such as a phone app or one of the delivery devices actingas a hub for this purpose. Where different devices deliver differentactive ingredients (whether type or concentration), this may also beaccounted for in modelling use, as a non-limiting example in relation topharmokinesis.

Multiple Data Sources

As noted above, and as shown in FIG. 6 , the obtaining processor mayreceive multiple user factors of the types described herein from one ormore sources, such as those in the delivery ecosystem 1, the Internet110, and records held by the feedback system 1012, for example at theserver 1000.

As noted above, these user factors may variously be classified asindirect or historical data; neurological or physiological data;contextual data; environmental or deterministic data; and/or use-baseddata.

In the case of use-based data, it will be appreciated that multiplesensors, and/or a sensor with multiple sensing capabilities may be usedin a sensor platform to obtain some or all of such use-based data.

Whilst the above description recites the sensor platform in relation toserving the feedback system, it will be appreciated that a deliverydevice such as an aerosol provision device may comprise a such sensorplatform anyway, independently of any feedback system, for example toprovide information to the user or some other device. Hence any suitableaerosol provision device may have a sensor platform comprising one ormore selected from the list consisting of a galvanic skin responsedetector, a heart rate detector, a touch detector, and any othersuitable detector described herein (for example, a cortisol detector);and the or each detector may be located on one or more selected from thelist consisting of a grip portion of the delivery device, a mouthpieceof the delivery device and an activation button of the delivery device,as appropriate. A further location for a sensor platform for one or moresensors is on an optional collar attachment arranged for example to fitbetween the cartomizer and the main body of the delivery device, orbetween the main body of the device and a mouthpiece, or between any twouser-separable components of the delivery device, as appropriate. Thecollar may be user-attachable, may be user-detachable, or may beintegral to the device. The collar may for example thus encircle andform part of the airflow path within the delivery device, and comprisethe (or a further) airflow sensor, for example to detect puff strengthor profile, or comprise one or more accelerometers or gyroscopes todetect one or more of device orientation, acceleration, velocity, orposition, or any other suitable sensors (e.g. a touch sensor). Thecollar can draw power from the delivery device for example whilstpassing power on to the cartomizer. The collar may also include aBluetooth® link and antenna (for example an annular antenna). The collarmay thus enable retrofitting of capabilities relevant to the techniquesherein to a delivery device that may otherwise be unsuitable, or onlyprovide more limited information.

It will be appreciated that different data sources relate to data thatspans different time periods; for example a single puff may take 1-3seconds, whereas the context of being at work may be true for hours oneither side of this event. Hence the obtaining processor may use datasources that by their nature precede, coincide with, and/or follow theoccurrence of other data sources, and correlations with a user's stateat a particular point in time (for example as indicated by a moretransitory even such as a puff) can take these wider perspectives intoaccount through any notable correlations.

However, as well as sources that are innately of long duration, it willbe appreciated that the techniques herein can use one or more sensors toobtain data that complements reading from other sensors by recordingdata, before, during, and/or after the readings by the other sensors.For example, a heart rate monitor may measure heart rate before, during,and/or after a puff or series of puffs. Hence data regarding the user'sstate may be usefully gained from the periods immediately preceding andfollowing the actual inhalation (or other measurable interaction) on thedevice, as well as during the inhalation.

It will be appreciated that any measurable parameter of interest couldbe recorded to provide time-localized context for measurements of anyother, although measuring such parameters on one or both sides of a puffaction in particular may be of benefit.

Whilst data from one or more such sensors can be continuously analyzed,this could require high processing resources and power consumption whichwould adversely affect the battery life of the delivery device.Consequently optionally the delivery device comprises a circular memorybuffer that is updated with values from the or each sensor used in thisscheme, thus using minimal processing. The buffer may comprise storagefor e.g. 5, 10, 15, 30, or 60 seconds of sensor readings, and isoverwritten during use in a circular manner.

When a puff is detected, the data in the buffer is collected forprocessing either on the delivery device, or via data transmission asdescribed elsewhere herein to a companion device such as a mobile phone,or to a remote server, either directly via data transmission or via thecompanion device.

When the puff is detected, optionally the data in the buffer iscollected for a further period of time roughly equal to half thecircular memory duration of buffer so that the puff event correspondswith the middle portion of the resulting buffer record, with datapreceding and following the puff event also recorded. It will beappreciated that the amount of buffer data recorded during and after thedetection of the puff event can be used to control the balance ofpreceding and following data recorded in the buffer; this may be of usedepending on whether the sensor data being recorded is of particularrelevance preceding the puff or following the puff, or balance of thetwo.

The recording following data may be relative to the detected start ofthe puff, or the detected end of the puff. Hence for example for a twosecond puff and a five second buffer, sensor data for one or moresensors other than the airflow sensor may be sent for analysis for thefive preceding seconds; or four preceding seconds and one second ofpuff; or three preceding seconds and two seconds of puff; or twopreceding seconds, two seconds of puff, and one following second; or onepreceding second, two seconds of puff, and two following seconds; or twoseconds of puff and three following seconds; or one latter second ofpuff and four following seconds; or five following seconds. It will beappreciated that division by fractional seconds is also possibledepending upon the sensor sample rate used in the buffer, as is divisionby greater than one second intervals.

Hence more generally the delivery device may comprise a circular bufferthat periodically records sensor data for one or more sensors other thanthe airflow/puff sensor, so that when a puff is detected to occur sensordata preceding, during and/or following the puff event can also beprovided for analysis, thereby providing time localized contextualsensor data in a power-efficient manner.

It will also be appreciated that more generally still any device withinthe delivery ecosystem may comprise a circular buffer that periodicallyrecords sensor data for one or more sensors other than the airflow/puffsensor, so that when a puff is detected to occur sensor data preceding,during and/or following the puff event can also be provided foranalysis. In this case the puff event may be signaled to the or eachother device for example via Bluetooth either directly or indirectly viaa companion device such as a phone. In this case optionally thecompanion device may collate the sensor data from one or more devices,potentially including itself, either for analysis by the deliverydevice, the phone itself, another device within the delivery ecosystem,or a remote server.

Obtaining Processor Operation

Turning again to FIG. 6 , the obtaining processor 1010 is typically partof a remote server 1000, and may receive user factors from diversesources such as the server's own storage/database 1012, on-line sources110, and devices within the user's delivery ecosystem 1, such as thedelivery device 10 itself, a mobile phone 100, a fitness wearable 400, adocking unit 200, a vending machine 300, and any other suitable devicethat may provide information relevant to the user's state, such as avoice-activated home assistant, smart thermostat, smart doorbell orother Internet of things (IOT) device.

The obtaining processor 1010 may comprise one or more physical and/orvirtual processors, and may be located within the remote server, and/orits functionality may be distributed or further distributed overmultiple devices, including but not limited to the user's mobile phone100, a docking unit 200, a vending machine 300, and the delivery device10 itself. The obtaining processor may comprise one or morecommunication inputs, for example via network connections, and/or vialocal connections to local storage. The obtaining processor may alsocomprise one or more communication outputs, for example via networkconnections, and/or via local connections, for example to the estimationprocessor 1020.

The obtaining processor may comprise pre-processors or sub-processors(not shown) adapted to parse and/or convert obtained information intouser factors where this information is not immediately usable as such;examples may include keyword or sentiment analysis of consumed media,for example to determine as a user factor a net positive or negativeinfluence on an aspect of user state, or similarly keyword analysis ofthe user's calendar to determine locations and events, for example againto determine as a user factor a net positive or negative influence on anaspect of user state. Other inputs, such as ambient temperature orprobability of rain, may similarly be converted to a scale appropriateto user factors, for example being normalized or classified according toinfluences on user state.

The obtaining processor may thus be operable to generate and/or relayuser factors for input to the estimation processor at varying degrees ofabstraction from the original source material.

Hence optionally original source data may be enumerated, codified,classified, formatted, or otherwise processed, or simply passed throughand provided as input to the estimation processor, so that there arepotentially as many or more inputs as there are original sources ofdata. As will be appreciated from the description above, this may resultin a large number of inputs.

Hence optionally one, some or all of the original source data may be anyrated, codified, classified, formatted, or otherwise processed, orsimply passed through as appropriate to an optional intermediate userfactor generation stage of the obtaining processor; this may determinepositive or negative influences from the submitted inputs on a specificsubset of user factors that may be relevant to the user state but notdirectly or easily measurable, such as effects on dopamine and/orcortisol, heart rate, satiety, and the like.

Similarly such an intermediate user factor generation stage of theobtaining processor may combine inputs from similar classes to generatea class-level user factor for one or more of the classes of datadescribed herein.

Hence as non-limiting examples, indirect or historical data could besummarized as how actively the user modifies or updates their device, orhow receptive they are to such modifications, on a given scale.Neurological or physiological data could be summarized as how stressedthe user appears to be, on a given scale, and/or their trajectory onthat scale. Contextual data could be summarized as how sociablydesirable use of the delivery device is currently, on a given scale.Environmental or deterministic data could be summarized by how likelythe user is to want to use the delivery device in a given timeframe; anduse-based data could be summarized as how frequently or deeply the useris or has recently used the delivery device.

It will be appreciated that in practice only source data from some orone of the classes may be available, and even where data from one classis available, a class-level user factor such as in the examples abovemay not be generated, or different kinds of class level user factor maybe generated depending on the type of data received within that class(e.g. different subsets of individual user factors); similarly,class-level user factors may be generated for input to the estimationprocessor in parallel with individual user factors.

The contributing values and/or influences from different individual,subset and/or or class level user factors may then be presented asinputs to the estimation processor, with the selection of class, subsetand/or individual user factors being chosen to give a gooddiscrimination between different user states.

For example, galvanic skin response may provide a good indicator of auser's state, and is also responsive to nicotine as an active ingredientby reducing the response; as such it may optionally be a candidate foran individual source of data to be used as an input to the estimationprocessor. Other physiological measures to provide good discriminationinclude muscle tension (EMG), heart rate, skin temperature, brainwaves(EEG), and breathing rate. Any of these, where available, may beconsidered for inclusion as an individual source of data, optionallyafter being any rated, codified, classified, formatted or otherwiseprocessed, alternatively or in addition combined in any combination withthese or other user factors described elsewhere herein.

Similarly location, social setting, time-of-day, and hormonal levels areall good indicators of the user's state and may be candidates for use asindividual sources of data as input to the estimation processor.

Hence more generally user factors may be obtained by or for theobtaining processor and provided to the estimation processor after anysuitable parsing or processing, either individually and/or as combinedsubset or class values with one or more others (for example based onweighted contributions, statistical functions, trained machine learningoutputs, look-up tables of precomputed correspondences between values ofthe obtained data and values of a target user factor, and the like), asfor example individual, subset and/or or class level user factors.

Estimation Processor

The estimation processor 1020 is operable to calculate an estimation ofuser state, based upon one or more of the inputs received from theobtaining processor comprising or based upon obtained user factors. Thecalculation of an estimation of user state can be either explicit togenerate an output reflective of a user's state prior to generating aproposed feedback action (which may be thought of as a two-operationprocess), or implicit to generate a proposed feedback action expected toalter a user's state (which may be thought of as a single operationprocess).

Like the obtaining processor, the estimation processor may comprise oneor more physical and/or virtual processors and may be located within theremote server, and/or its functionality may be distributed or furtherdistributed over multiple devices, including but not limited to theuser's mobile phone 100, a docking unit 200, a vending machine 300, andthe delivery device 10 itself. The estimation processor may comprise oneor more communication inputs, for example to receive data from theobtaining processor 1010. The estimation processor may also comprise oneor more communication outputs, for example to provide a proposedfeedback action to the feedback processor 1030.

Explicit State Estimation

In an embodiment of the description, in a two-operation process theestimation processor initially explicitly estimates a state of the userin a first operation before then generating a proposed feedback actionin response to the estimated state in a second operation. This estimatedstate may itself take the form of a single value or category, or may bea multivariate description of the user's state.

As non-limiting examples of a single value state, the estimated statemay describe:

-   -   i. a stress level of the user;    -   ii. a degree of benefit the user is expected to subjectively        experience in response to a unit consumption of a proposed        active ingredient; and    -   iii. a social flexibility score, indicative of how easily the        user can currently use the delivery device and hence alter their        state through modification of delivery;

As non-limiting examples of a state category, the estimated state maybe:

-   -   i. one of a plurality of state classifications, all, some, or        none of which may correspond to what are colloquially referred        to as moods; hence for example happy, sad, low cortisol, medium        cortisol, high cortisol, calm, stressed, receptive to change        (for example willing to use their delivery device to alter their        state), or unreceptive to change.    -   ii. one of a plurality of state classifications chosen to have a        subsequent clear correlation with either inputs from the        obtaining processor and/or an available feedback action, the        classifications not necessarily fitting a notional category such        as ‘happy’ or ‘high cortisol’, but having classification        boundaries driven at least in part by their correspondence to        either the available inputs from the obtaining processor or        outputs for the feedback processor.

As non-limiting examples of a multivariate description of the user'sstate, the estimated state may comprise:

-   -   i. the user's stress level according to physiological        indicators, and separately according to contextual indicators,        together with an indication of their current social flexibility        based on time-of-day, location, and/or proximity to specific        individuals;    -   ii. an indicator of the user's physiological state based upon        galvanic skin response and heart rate, together with current        position in a hormonal cycle, and indicators of mental state        derived from questionnaire and/or social media analysis.

These examples may be used to provide non-limiting illustrations of theoperation of the estimation processor, as follows.

The estimation processor may use predetermined rules, algorithms and/orheuristics to convert input data from the obtaining processor intoestimated states.

-   -   For example, a single value state such as a stress level of the        user may be derived by applying a predetermined combination to a        plurality of user factors, such as a weighted sum, with the        result normalized according to the number of currently available        inputs contributing to the sum.    -   Similarly a single value state such as the degree of benefit        expected for the user may be derived by estimating the user's        positive or negative emotional state based upon summing        indicator values for positive or negative keywords or sentiments        in on-line media recently consumed or produced, and positive or        negative values associated with a classification of the user's        location.    -   Likewise an estimated state category may be selected by template        matching user factor values to predetermined values indicative        of a given category, or similarly identifying a        least-mean-squares error between user factors and a template of        user factor values for each candidate category, optionally with        different categories and greater error having different linear        or non-linear weightings, reflecting their relative salience in        identifying the category.    -   Finally as an example, a multivariate state may comprise        deriving individual indications of state according to any of the        above examples; hence a single value stress level may be        generated as discussed above for each of physiological and        contextual indicators, and a social flexibility value may be        determined based upon scores previously associated with        different times of day, location and class of specific        individual (e.g., partner versus child); or a social flexibility        classification may be based matching templates to such scores        and/or values for the underlying input data.

Alternatively or in addition, the estimation processor may use look uptables to convert input data from the obtaining processor into estimatedstates.

In one instance, these look up tables may simply provide a precomputedimplementation of the above predetermined rules, algorithms and/orheuristics, to avoid repetition of these calculations either at theserver, or on a device within the delivery ecosystem that has limitedprocessing capability but is acting as the estimation processor orsharing its role, such as the delivery device 10, or a dock 200, vendingmachine 300, wearable device 400, or associated phone 100.

In another instance, such look up tables may provide associationsbetween input values from the obtaining processor and output values ofuser states, state classifications and/or multivariate states previouslyderived according to any suitable mechanism, such as for examplefeedback from extensive user testing, or as described later herein, theoutput of a machine learning system; again in this latter case, a lookup table may potentially provide a computationally simpler facsimile ofsuch a machine learning system by recording pairs of inputs and outputsfor common values that may be easier to implement on devices within thedelivery ecosystem having a comparatively low computational power.

Alternatively or in addition, the estimation processor may modelcorrelations between input data and estimated states of the user. Suchcorrelations may be due to causal links between a user factor and a userstate, or a tendency for the user factor to accompany a cause of theuser state, hence acting as a proxy, typically with particular degree ofprobability. Similarly such correlations may be due to the user factorand the user state both responding to a separate cause or circumstancein a manner that is sufficiently repeatable to form a correlation.Likewise such correlations may be due to the user state giving rise tothe user factor. Hence more generally correlations relate to measurablypredictable correspondences between one or more user factors (whetherindividual, subsets or class level user factors as output by theobtaining processor) and a user state (whether a single value, aclassification or multivariate), typically either due to a causal link(in either direction between user factor and state), a common causeresulting in responses in user factor and user state with a repeatablerelationship at least at a statistical level, and/or a measurablecorrespondence regardless of whether a direct or indirect causal link isknown.

Where the estimation processor models correlations, it can be trainedusing a data set comprising as inputs data corresponding to the abovedescribed outputs of the obtaining processor, and as target outputsdescriptors of a state of the user, whether single value, aclassification, or multivariate, for example based upon a directmeasurement of a user's state and/or user self-reporting regarding theirstate.

The specific means by which such correlations may be derived include anysuitable technique for estimating such correlations, including acorrelation map between inputs and outputs, where presentation of aninput and output at the same time (or within a predetermined timewindow, if a temporal factor is included) results in a reinforcement ofthe link between the specific inputs and outputs (for example byincrement of a connective weight). Once trained on the dataset, a newinput will result, by virtue of the connective weights, in theactivation to a greater or lesser extent of one or more candidate statescorrelating with that input; the candidate state with the strongestactivation may then be chosen as the user state, or such states may beranked by activation strength. It will be appreciated that in such asystem, multiple input values may be provided simultaneously,corresponding to individual, subset of class level user factors asdescribed elsewhere herein, and the generated outputs may correspond toa single value state, a classification, or a multivariate state with anumber of values representing different aspects of the user state asdescribed elsewhere herein being output.

A specific example of a correlation map is a neural network, and anysuitable form can be considered.

More generally, any suitable machine learning system capable ofdetermining a correlation or other predictable correspondence betweenone or more inputs and one or more outputs may be considered.

Given the above described dataset, such machine learning systems aretypically supervised and may for example be a supervised classificationlearning algorithm, for example if the user state is a classification;or a supervised regression learning algorithm, for example if the userstate is a single value or multivariate. Other forms of machine learningare also suitable, such as reinforcement learning or adversariallearning, or semi-supervised learning. Furthermore multiple independentmachine learning systems separately trained on different or partiallyoverlapping individual, subset or class level outputs of the obtainingprocessor can be ensembled to improve modelling results, for example toaccommodate different configurations of source data due to differentpatterns of ownership of devices in the delivery ecosystem of differentusers, and different permissions and habits affecting the availabilityof online sources of information. It will also be appreciated that amixture of different machine learning systems can be used in parallel,for example to generate a multivariate state of the user, with forexample one or more different elements of the multivariate descriptionbeen generated by different respective machine learning systems. Theserespective machine learning systems can be on separate hardware (e.g.based on dedicated neural processors) but more typically may be on thesame hardware (e.g. software based machine learning systems that areloaded and run as required).

Meanwhile unsupervised learning algorithms may also be considered; hencefor example associative learning may determine the probability that ifone input or pattern of input is present then the user will be in agiven state.

Examples of the above machine learning systems, in the forms ofalgorithms and/or neural networks, will be known to the skilled person.

Meanwhile machine learning may optionally also be used to prepare (e.g.pre-process) data, either at the estimation processor and/or in theobtaining processor; hence for example clustering (for example k-meansclustering) may be used to classify a diverse set of inputs into a classlevel user factor of the type described previously herein. Such anapproach may be used or also used for example to derive classificationsfor user states, as per the second example of a state categoryclassification described previously herein, in response to inputs fromthe obtaining processor or available feedback actions of the feedbackprocessor.

Similarly as a preparatory operation at the estimation processor and/orobtaining processor, dimension reduction, such as principal componentanalysis, may be employed to reduce the number of inputs whilstretaining information having a significant correspondence with the userstate.

Hence in summary the estimation processor, if generating explicitestimates of user state, uses a repository for the correspondencebetween available inputs from the obtaining processor and the estimatedstates, where that repository for the correspondence may be embodied inalgorithms, rules or heuristics, and/or in one or more look up tables,and/or in one or more trained machine learning systems.

In each case, the result is an estimation of the user state, which maytake the form of a single value, a category, or a multivariatedescription/representation of the user state as described previouslyherein.

Meanwhile the operation of the estimation processor if generatingimplicit estimates of user state, is described later herein.

Feedback Proposals from an Estimated State

As noted previously herein, the estimation processor may operate in atwo-operation process; in the first operation estimating a user statefrom inputs comprising one or more user factor or data derived from suchuser factors by the obtaining processor, as described previously herein,and in the second operation generating a proposed feedback actionexpected to alter a user's state, as will be described below.

In principle, the second operation may be implemented by the feedbackprocessor rather than the estimation processor, or may be shared betweenthe feedback processor and the estimation processor. Alternatively thefeedback processor may simply receive the proposed feedback action. Inany case, the feedback processor may then select the feedback action(either by default if only one is proposed, or selecting one or more ifa plurality are proposed), or optionally act to cause one or morefeedback actions proposed by the estimation processor to occur in anappropriate manner within the delivery ecosystem.

For the purposes of explanation, the second operation is describedherein as occurring within the estimation processor.

The two-operation process may be chosen for practical reasons; forexample, training sets for use in modelling thecorrespondence/correlation between user factors or their derivations bythe obtaining processor and user state may be easier to generate oracquire than training sets for use when directly modelling thecorrespondence/correlation between user factor based inputs and proposedfeedback actions, because the user's state may be either directlymeasurable, or straightforward for a user to report.

Similarly it may be easier to generate a training set determining thecorrespondence/correlation between a measurable and/or self-reporteduser state and a proposed feedback action, based for example upon userquestionnaires ranking feedback actions for given states, and/or uponthe subsequent effectiveness of an implemented feedback action inaltering the state of the user toward a more desirable state, asmeasured and/or reported by the user. The optional timing of such aquestionnaire is described elsewhere herein. Typically a more desirablestate is one which improves the user's subjective sense of well-beingand/or moves physiological or neurological indicators of the user'sstate toward a preferred norm (for example reducing elevated heart rate,galvanic skin response, elevated skin temperature, and/or breathingrate, and the like).

The input for the second operation will typically be an estimation ofthe user state, represented by a single value, a category, or amultivariate description as described previously herein, or a pluralityof these if multiple states are estimated (for example with varyingdegrees of activation/strength of correlation in response to the inputsof the first operation). Optionally, inputs to the second operation mayalso comprise one or more user factors and/or inputs as provided by theobtaining processor; for example, as described elsewhere herein certainphysiological measurements may be useful indicators/proxies for the userstate, such as galvanic skin response, heart rate, breathing rate, skintemperature and the like. Hence optionally one or more of these or anyother inputs to the first stage, may also be provided for the secondstage in conjunction with the or each estimated state.

In any event, as with the estimation of the user state, the generationof a proposed feedback action may use any suitable mechanism thatembodies a correspondence/correlation between the estimated user stateand the proposed feedback action.

As noted previously, this may include predetermined rules, algorithmsand or heuristics to convert estimated states into proposed feedbackaction.

-   -   For example, a single value state (such as degree of stress) may        drive a corresponding proposed feedback action, such as        increasing the proportion of active ingredient within an inhaled        unit volume of generated aerosol, which in turn may be achieved        by modifying heater, air flow, reservoir and/or other payload        storage settings, and the like, which as described later herein        may be managed by the feedback processor. The relationship        between the degree of stress and the change in active ingredient        may be linear or non-linear, or may change qualitatively at        different values, for example not changing at all for low levels        of stress, have a linear relationship for medium levels of        stress, and have an asymptotic relationship for high degrees of        stress up to a maximum proportion of active ingredient, and for        example at or near this maximum also modifying a behavior of the        user interface of the delivery device or other device within the        ecosystem, such as issuing a warning or calming message on the        user's phone.    -   Meanwhile for example a single category state may have a        corresponding proposed feedback action.    -   Finally for example a multivariate state may result in a        corresponding proposed feedback action being based on weighted        or unweighted contributions from the different elements of the        state description, and/or different feedback actions may be        proposed based on overlapping or non-overlapping subsets of the        elements of the state description. Hence for example if the        state description suggests that the user is stressed and are in        a work environment, then the feedback action may assume that        they are implicitly stressed because they are in the work        environment, but are currently unable to increase their intake        of active ingredient, and therefore issue a message on a UI of        the delivery device or other devices in the ecosystem, such as        the user's phone, to suggest the user that they take a break.        Meanwhile if the user is stressed but not in their work        environment, then the feedback action may be similar to the        degree of stress example above, resulting in an increase in the        proportion of active ingredient delivered to the user.    -   As noted above, any one of these may also be accompanied by one        or more inputs to the first operation.

Again like the estimation of user state, the estimation processor mayalternatively or in addition use look up tables to convert stateestimation data into proposed feedback actions.

Alternatively or in addition, again like the estimation of user state,the estimation processor may model correlations between estimated userstates and proposed feedback actions, and the use similar techniques todo so.

Where the estimation processor models correspondences/correlations, itcan be trained using a data set comprising as inputs data correspondingto the estimated user state (for example in the form of single values,classifications, or multivariate descriptions, or a combination ofthese) and optionally also inputs from the obtaining processor asdescribed previously herein, and as target outputs proposed feedbackactions.

The proposed feedback actions are discussed in more detail later herein,but may typically comprise at least one type of action and optionallyone or more variables characterizing the performance of that action.Hence for example a change in vaporization temperature is a type ofaction, and an increase or decrease, or amount of increase or decrease,would represent a variable characterizing the performance of thataction. Similarly modifying active ingredient concentration in theaerosol is a type of action, and an increase or decrease inconcentration, or an amount of increase or decrease, would represent avariable characterizing the performance of that action.

Hence as a non-limiting example in the context of a machine learningsystem, different output nodes may represent different types of action,and the values of those nodes may represent either a flag indicatingselection of that feedback action, or a value relating to a variable ofthat feedback action, depending on how the system is trained. It willalso be appreciated that multiple output nodes may be associated withone or more types of action in a machine learning system, depending onthe training regime.

It will be appreciated that potentially a plurality of feedback actionsmay be indicated in response to an estimated user state. In suchcircumstances, the feedback processor may subsequently determine whetherto select just one feedback action, for example based upon the degree ofchange caused by the action as implied by its associated variable orvariables, or implement multiple feedback actions in parallel orsequentially, in the latter case optionally a sequence determined by apredetermined order, or again responsive to the strength of activationof a flag output node for each feedback action, and/or the degree ofchange implied by each action's associated variable or variables.

It will also be appreciated that to train such a machine learningsystem, measured and/or reported user states could be provided asinputs, and respective proposed feedback actions could be provided astargets, with actions and values selected according to their reportedefficacy during user trials for users having the corresponding userstate; again in this case efficacy or effectiveness typically relates tothe user's perceived improvement in state, and/or a change inneurological and/or physiological state toward a predetermined norm orpreferred state.

Optionally as first training phase, simulated states and correspondingfeedback actions could be used to provide initial training (for examplebased on questionnaire results as described previously), with aproportionally smaller cohort of real-world training data then beingused to refine the model.

Optionally, feedback from the user themselves as to the efficacy and/orsuitability, desirability, practicality etc., of any feedback actionscould be further used to refine the model and effectively personalize itto the user. Again this feedback may be reported by the user for examplevia a user interface on a device within the delivery ecosystem such asthe delivery device or their phone, and/or based on measurements ofneurological and/or physiological response. Where plural feedbackactions are implemented or indicated, optionally the user may rank themin order of preference.

In summary, the two-operation process, comprising an explicit estimationof user state as a first or interim operation, may be of use where theseoperations better fit the available underlying empirical data sets usedto model the correspondences/correlations, whether this is done byrule-based techniques or machine learning.

Objectively, the operation of the estimation processor in this mode isthus to take inputs from the obtaining processor, typically in the formof different individual, subset and/or or class level user factors, andoutput one or more proposed feedback actions either simply identifyingthe action in a manner similar to a flag, and/or identifying the degreeof relevance of that action to the estimated state based on theactivation level and output corresponding to the proposed feedbackaction, and/or indicating a change or amount of change of one or morevariables that at least in part characterize the proposed feedbackaction.

The explicit estimation of the user state is thus typically an internal,interim operation. However it will be appreciated that this estimatecould be relayed to the user for their information, and optionally theuser could modify the estimate, particularly where the estimate or acomponent of the estimate in a multivariate description relates to asubjective measure or to a proxy of a subjective measure such as theuser's sense of stress. Hence for example the estimate could bedisplayed on a user interface of the user's mobile phone, and the usercould use this information to self-assess, and make changes to theestimate as a result. The modified estimate of the user's state couldthen be used together with or instead of the originally generatedestimate in the second operation to generate a proposed feedback actionthat may be more accurate than the proposal based on the originalestimate of the user's state.

Furthermore, any changes made to the estimate of the user's state couldbe used to update and refine the model of the first operation, andindeed for certain machine learning techniques, a lack of correction bythe user may similarly be taken as a positive reinforcement of theestimate for the purposes of training.

As mentioned previously herein, if further training is not desired, thenoptionally the relationships between input and output values derived bythe machine learning process may be captured in one or more look uptables, which may be computationally simpler to use (though may occupymore memory).

Implicit State Estimation

In an embodiment of the description, rather than using the two-operationprocess described above, the estimation processor performs a singleoperation process that implicitly estimates a state of the user as partof the relationship between individual, subset and/or or class leveluser factors provided as input by the obtaining processor, and proposedfeedback actions generated as an output and typically expected to altera user's state.

Hence an estimation processor (1020) adapted to calculate an estimationof user state based upon one or more of the obtained user factors mayequally be an estimation processor (1020) adapted to generate a proposedfeedback action state based upon one or more of the obtained userfactors; in this case the user state is implicit in the relationshipbetween the user factors and the proposed feedback action, which isexpected to alter the implicitly estimated state of a user.

In a similar manner to the two-operation process described previouslyherein, the estimation processor may use predetermined rules, algorithmsand/or heuristics to convert input data from the obtaining processorinto estimated states. These may for example combine the processes forthe two separate operations of the explicit state estimationembodiments, and/or refine some or all of the rules, diagrams and/orheuristics in response to the single operation nature of the implicitstate estimation approach, or may be derived from scratch for the singeoperation process.

Again like the two-operation process, the estimation processor mayalternatively or in addition use look up tables to convert input datainto proposed feedback actions. Again these may be concatenations oflook up tables from the two-operation approach, and/or may be furtherprocessed to provide single operation look-up tables, or may be derivedfrom scratch for the singe operation process.

Again like the two-operation process, the estimation processor mayalternatively or in addition use machine learning. In this case forexample, inputs used in the first operation of explicit stateestimation, and targets used in the second operation of generatingproposed feedback actions from the estimated operations, may be used totrain a machine learning system that identifies measurablecorrespondences between them.

It will be appreciated that to present corresponding inputs and targetsfor training purposes, the training set should have captured thiscorrespondence; as noted previously herein, it may be that datasetsexist for the inputs and a user state, and user states and effectivefeedback actions; consequently inputs and feedback actions can bemarried for training purposes based upon the common user state value,class or multivariate descriptors as appropriate; clearly also where thetraining datasets were collected by users for whom user factors weremeasured and/or self-reported, user states were measured and/orself-reported, and subsequent efficacy and/or suitability, desirability,practicality etc., of feedback actions were measured and/orself-reported, then these self-consistent sets of input user factors (asprovided by the obtaining processor) and target feedback actions can beused for training.

Alternatively or in addition, a two-operation system with explicit stateestimation, which has been trained on separate datasets, and/or usesrespective rules, algorithms and/or heuristics from the two operations,and/or uses look up tables from the two operations, can be used as adata source.

For example, a single operation look-up table may be created by runningthrough the first and second operations of look-up tables or rules,algorithms and/or heuristics, and/or machine learning systems for atwo-operation estimation to provide look up links between inputs asprovided by the obtaining processor, and proposed feedback actionsgenerated by running through the two-operation process using thoseinputs.

Alternatively or in addition, a single operation machine learning systemmay be trained by running through the first and second operation of lookup tables or rules, algorithms and/or heuristics, and/or machinelearning systems for a two-stage estimation to provide inputs asprovided by the obtaining processor, and provide as targets for trainingproposed feedback actions generated by running through the two operationprocess using those inputs.

Optionally, a single operation machine learning system trained in thismanner may then have its training refined using additional data, such asa combined training set as described above and/or, in a similar mannerto that described previously herein for the operation scheme, datareceived from one or more users during use of the user feedback system.

It will also be appreciated for example that a training set may be baseddirectly on capturing the desired input and target values rather thanusing an amalgam of datasets or processes.

It will be appreciated that for either the two-operation approach or thesingle operation approach, training data may be gathered using one ormore devices in the delivery ecosystem, for example to build a trainingset relating user factors to user states. Such a training set may begenerated using a version of the user feedback system that does notgenerate a proposed feedback action, but simply gathers the user factorsand user state information. Similarly a training set relating userstates to proposed feedback actions may initially be based upon askingusers, for whom their state is known (e.g. measured/reported) to rateproposals for feedback actions, for example via a user interface ontheir phone as part of a user testing scheme. Hence in this case thefeedback system may propose feedback actions and select one or more ofthe proposed actions, but in different versions or modes may eitherpresent the selected proposed feedback action(s) to the user forevaluation (for example via a user interface) for example during atraining-data gathering phase or a calibration phase (for example tocharacterize the user within a subgroup to which responses may be bettertailored, as disclosed elsewhere herein), and/or may cause the selectedproposed feedback action(s) to be implemented, either modifying of oneor more operations of at least a first device within the deliveryecosystem, or prompting the user to do so, responsive to the estimationof user state (whether explicitly or implicitly modelled), in a mannerexpected to alter the estimated state of a user. Training data relatinguser factors to proposed feedback actions may be obtained in a similarmanner.

Hence such datasets may be obtained using a version or mode of the userfeedback system that as noted above does not actually cause amodification to one or more operations of a device in the ecosystem(optionally except for eliciting a response from the user, e.g. fortraining data purposes).

This preceding generation of the user feedback system, ortraining/refinement mode of the user feedback system, could thuscomprise an obtaining processor (1010) operable to obtain one or moreuser factors indicative of user state, and operable to obtain user statedata (for example based on measurements similar to those of userfactors, and/or self-reporting by the users), and or feedback actionpreference/efficacy data; the estimation processor would then comprise atraining or development phase in which thecorrespondences/relationships/correlations between inputs based on theuser factors as described previously and targets based on the userstates (in the two-operation scheme) or the proposed feedback actions(in the single-operation scheme) are modelled as described previously,for example once a sufficient corpus of data had been amassed.

Alternatively or in addition, in such a preceding generation and/or in atraining mode of a feedback system, the delivery device and/or otherparticipating devices in the delivery ecosystem may consequently onlyupload data to the obtaining processor, but not download feedbackactions (or optionally any other data) from the feedback system.

Similarly, in either such a preceding generation and/or in a trainingmode of a feedback system, and/or in providing improved or supplementaryinput for the feedback system in normal use, then as mentioned elsewhereherein user factors such as from neurological/physiological data (e.g.from biometric sensing), motion and/or location user factors (e.g. fromtouch, accelerometer or GPS sensors), contextual user factors, and/orany of the other user factors disclosed herein may be accompanied bydirect input on the user's state as reported by the user. This may beused for the generation of a training set, as described previously, butalternatively or in addition the user's reported state may be treated asa user factor by the obtaining processor, or directly by the estimationprocessor.

The user's reported state may be obtained based upon results of aquestionnaire presented to the user, for example via a user interface ona device within the delivery ecosystem such as for example the user'smobile phone or delivery device. Such a questionnaire may simply ask theuser to select a state that best approximates their subjectiveunderstanding of their own state, for example from a menu or drop-downbox, and/or may ask questions to which the choice of answer by the usercan be indicative of the user's state. Such a questionnaire may beprovided periodically, or in response to some event, for examplerelating to a detected user factor or a value associated with the userfactor reaching a certain threshold. Hence for example a questionnairemay be provided in response to certain calendar events, or in responseto a user visiting a certain location, or a user's heart rate exceedinga predetermined threshold. Optionally the frequency with which aquestionnaire is provided to the user may be limited, so that the userdoes not become annoyed by the questionnaire process. Similarlyoptionally the extent of the questionnaire may be varied so that directself-assessment is more frequent than assessment based on responses toquestions as described above, where this is provided.

More generally, and also in relation to other questionnaires describedherein, the presentation of, offer to present, or request to fill in, aquestionnaire to the user may optionally depend on a number of factors.For example, questionnaires about the user's cultural background mayonly need to be done once e.g. as part of an initial set up process, andoptionally confirmed e.g. annually. Meanwhile other questionnaires maybe periodic, e.g. monthly or weekly, or passively await update from theuser, such as the user's current weight. Further questionnaires may beevent based, for example in response to a detected deviation in pufffrequency or behavior, or in response to a feedback intervention. Inthese cases, optionally there is also a time-out in which the same orother questionnaires are not asked within a predetermined period (e.g.1-N hours or a day), so as to avoid overwhelming the user. Optionally ifthe user has agreed to more intensive questioning (e.g. as part of asystem training program) then questionnaires may be asked moreregularly, e.g. ever couple of hours, when the user is awake.

In principle the user's reported state may optionally be used in lieu ofan explicit state estimation by the estimation processor, but it ispossible that at least in some cases the user's reported state will beapproximate compared to what may be derivable, or estimated from somemeasurements (if these are available), or the user may not be informedby all the facts available to the feedback system. Furthermore, someusers may normalize their state and self-report in a biased manner,particularly for pathological states such as depression. Henceoptionally the user's direct input on their state may be used inconjunction with one or more other user factors from the obtainingprocessor as described above as input to the estimation processor, inthe first (or only) operation as described above. Optionally,alternatively or in addition the user's direct input on their state maybe used in conjunction with an estimation of their state as input to thesecond operation of the estimation processor, if the two-operationtechnique is used.

Other variations in training and input may also be considered. Forexample it will be appreciated that as noted previously herein,different user factors operate or vary over different time scales.Consequently for either the two-operation approach or the singleoperation approach for the estimation processor as described herein,user factors that are not expected to have changed within an intervalbetween successive operations of the estimation processor may be storedand re-used (for example in storage 1012), rather than beingre-obtained.

Furthermore, some parts of the estimation model relating to these longerterm factors may not need to be re-run if the outcomes for those factorsare expected to remain the same. This may be straightforward for rule,algorithm and/or heuristic methods, and/or look-up tables, but for amachine learning system it may require a modified architecture; forexample a two-stage ML or multi-layer system may be trained on allinputs, but subsequently run with inputs or outputs relating tolong-term user factors clamped, and the previously computed intermediateresults of that part of the ML system fed into the remaining part of theML system in conjunction with newly generated intermediate results fromuser factors with shorter time frames.

It will also be appreciated that as noted previously herein, differentusers may have different combinations of devices within their deliveryecosystem, and/or different combinations of these devices may be activeat any one time; similarly, different users may have greater or lesserpresence on social media, or use their digital calendar to a greater orlesser extent, and the like. Consequently the user factors available tothe obtaining processor and hence also the inputs available to theestimation processor may differ from user to user, and/or from time totime. Accordingly, the estimation processor may use different models(explicit or implicit, as discussed above) to propose feedback actions,depending upon the inputs available. Alternatively or in addition, wherean input to a model is missing, a neutral input value may be provided soas to reduce or remove the influence of that missing input on thefeedback action proposed. The number of different models provided by/forthe estimation processor may therefore depend upon the number of datasources assumed for a model (with more sources or more diverse sourcesmaking the model potentially more fragile), and the robustness of themodel to the replacement of inputs with placebo/neutral values where aninput is currently unavailable; in this latter case it will beappreciated that some inputs may be more critical than others, so atleast some individual inputs may be required for a model to run. Hencedepending upon the complexity and robustness of the model, it may bethat only one model is needed, or a suite of models anticipatingdifferent scenarios. Optionally, a subset of all available models isselected for a user depending upon the devices known to exist in theirdelivery ecosystem; meanwhile new models may be added when new devicesjoin the delivery ecosystem, whether permanently for example in the caseof the user buying a new dock 200, or temporarily for example in thecase of the user interacting with a vending machine or point-of-saledevice.

Estimation Processor Output

Whether a single operation or two operation process is used, and whetherthe estimation for any operation is based on rules, algorithms, and/orheuristics, look up tables, and/or machine learning, the output of theestimation processor is a proposed feedback action.

Possible feedback actions differ qualitatively and/or quantitatively.

Hence for example they may vary qualitatively based on whether theyrelate to modifying the generation of aerosol for the user (whether inresponse to current circumstances or pre-emptively); modifying theuser's interaction with the delivery device or system, either duringinhalation or between inhalations; modifying the user interface of thedelivery device or system; reminding the user to use or change their useof a delivery device or system; recommending an operation or selectionof a delivery device or delivery device consumable; and/orrecommending/activating/modifying the operation of a device that is notdirectly related to the delivery of active ingredient, but maynevertheless change the user's state, either directly (for examplethrough biofeedback) or indirectly (for example by activating noisecancellation in a user's headphones).

Hence more generally feedback actions may fall into categories that arebehavioral, focusing on altering actions and/or habits of the user tochange their state; pharmaceutical, focusing on how one or more activeingredients delivered to the user may change their state; andnon-consumption interventions, focusing on alternative first or thirdparty options (i.e. relating to the delivery device or other devices inthe delivery ecosystem or elsewhere) to change a user's state.

Meanwhile proposed feedback actions may vary qualitatively depending onthe extent to which the effect of the feedback action is desired to makea positive change in the user's state; hence for example in the deliverydevice a change to heater temperature, payload aerosolization, payloadcomposition, or the like may comprise a quantitative value indicatingthe degree of change, or class of change, as appropriate. Similarlymodifications to a user interface in the delivery device or anotherdevice of the delivery ecosystem may comprise incremental operationsrelating to the number of user interactions required or prompted withthe delivery system, and the nature of those user interactions; forexample running through five categories, with the first category havingno notifications to minimize interruption of the user, a second categoryonly having critical notifications such as for low battery or lowpayload, a third category corresponding to a default in which criticaland non-critical notifications are provided, a fourth category furtherincluding recommendations and/or prompts to engage the user with otherfeatures of the user interface, and a fifth category additionallyincluding an audible tone. These five categories may be selectedaccording to the user state on a scale of how stressed they are (forexample with minimal notifications for high stress), and/or how boredthey are (for example with high notification for high boredom).

As noted previously, the type of feedback action, and/or the amount orclass of change, if appropriate, may be identified according to rules,algorithms, and/or heuristics, look up tables, and/or machine learningas appropriate.

Similarly as noted previously, where more than one type of feedbackaction, and/or more than one amount or class of change iscalculated/estimated to be an appropriate response to the userfactors/user state, optionally multiple feedback actions may be proposedaccordingly, or the top N feedback actions may be selected based forexample upon strength of activation, where N may be one or more.

Feedback Processor

The feedback processor 1030 is operable to implement one or moreproposed feedback actions, thereby causing modification of one or moreoperations of a device within the delivery ecosystem, responsive to theestimation of user state.

Hence the feedback processor may act to cause the feedback action oractions proposed by the estimation processor to occur in an appropriatemanner within the delivery ecosystem.

The feedback action or actions are typically implemented in a mannerexpected to alter the estimated state of a user. This user may beconsidered a generic, average, notional user; it will be appreciatedthat the model or models upon which the generation of the proposedfeedback action(s) is/are based are typically developed or trained usingdata from a corpus of users, and hence relate to changing the state of ageneric, average, or notional user.

However, typically this will nevertheless similarly alter the state ofthe particular user of a respective delivery device, on the basis thatmost users are likely to respond in a similar manner to these changes.

However as described elsewhere herein, if the feedback system canreceive further feedback from the individual user (for example bymeasurement or self-reporting) as to the efficacy of proposed feedbackactions, then optionally the system can become increasingly tailoredtowards the particular user, for example through supplementary trainingand/or refinement of parameters, and hence implement feedback actionsresponsive to the estimation of user state in a manner expected to alterthe estimated state of the particular user. Similarly, separate rules,algorithms, and/or heuristics, look up tables, or machine learningsystems may be generated for different user groups, for example based ondemographics and/or patterns of response to feedback actions, so thatthe proposed feedback actions are better tailored to a particular userfalling within one of these groups, even if measured or reportedassessments of feedback efficacy are not available from the particularuser, or are too sparse to effectively refine the training of a machinelearning system or alter the parameters of an algorithm etc., topersonalize its response to them.

Like the obtaining processor and the estimation processor, the feedbackprocessor 1030 may comprise one or more physical and/or virtualprocessors and may be located within the remote server 1000, and/or itsfunctionality may be distributed or further distributed over multipledevices within the delivery ecosystem, including but not limited to theuser's mobile phone 100, a docking unit 200, a vending machine 300, andthe delivery device 10 itself. The feedback processor may comprise oneor more communication inputs, for example to receive data from theestimation processor 1010, and one or more communication outputs, forexample to communicate with the delivery device 10, and/or anotherdevice within the delivery ecosystem 1 such as those listed above, orany other device that may participate in a feedback action.

In particular, the feedback processor may optionally comprise aselection and notification sub-processor (not shown) which may belocated at the server and/or at a device within the delivery ecosystemwith suitable computational power, such as a vending machine or mobilephone, to optionally select one or more feedback actions and select oneor more respective devices within the ecosystem for implementing one ormore feedback actions; and optionally an action implementationsub-processor (not shown) at one or more respective devices within theecosystem for managing the implementation of a feedback action.Optionally, the action implementation sub-processor may be considered aseparate processor to the feedback processor.

Herein, references to the selection and notification sub-processor andthe feedback processor, or the action implementation sub-processor andthe feedback processor, may each be considered interchangeable; it willbe appreciated that whilst these sub-processors may be complementaryhardware to the feedback processor, and/or effectively share a role ofthe feedback processor, they may equally be functions of the feedbackprocessor operating under suitable software instruction. Meanwhile asnoted above, optionally at least the action implementation sub-processormay be a separate processor to the feedback processor, for examplecommunicating with the feedback processor via the Internet.

Selection and Notification

Optionally, the selection notification sub-processor may select one ormore feedback actions generated by the estimation processor in a manneras described previously herein, if the estimation processor indicatesmore than one feedback action may be appropriate. Clearly, if only onefeedback action is proposed, then as a default this would be selected.

For a selected feedback action, the selection notification sub-processormay then select which device or devices within the delivery ecosystemshould implement the feedback action, and formulates acommand/notification/instruction for the or each device characterizingthe type and/or amount of the feedback action. It will be appreciatedthat where a device is only capable of one feedback action, then thetype can be implicit in the act of notification, and similarly where adevice is only capable of one amount feedback action, then the amountcan be implicit in the act of notification. Any device within thedelivery ecosystem could potentially comprise a feedback means. It willbe appreciated therefore that potentially the device or devices thatprovide user factor data to or for the obtaining processor within thedelivery ecosystem are different to the device or devices implementingthe or each feedback action.

Optionally, the selection notification sub-processor may poll deviceswithin the delivery ecosystem to determine their availability for thepurposes of providing a feedback action. For devices that may beaccessible by the processor, for example by the Internet, then devicesregistered in association with the user or the user's delivery device(such as for example the delivery device 10, mobile phone 100, wearabledevice 400, docking device 200) may be polled directly.

For devices that may only be accessed via an intermediary device, forexample via Bluetooth® connection to an accessible device, theaccessible device may be asked to poll such indirect devices. Hence forexample the selection notification sub-processor may cause/request theuser's mobile phone 100 to poll a delivery device 10, wearable device400 or docking device 200, if these are only accessible via a localwired or wireless connection.

For devices that are not formally associated with the user or onlyintermittently associated with the user, such as a vending machine 300or other point of sale system, the selection notification sub-processormay receive location data from a device within the delivery ecosystemassociated with the user, such as their mobile phone 100 or deliverydevice 10, and compare this with a registered or reported location ofthe vending machine 300; if the locations are within a thresholddistance of each other, then the vending machine may be considered partof the delivery ecosystem whilst that condition holds true.Alternatively or in addition, the selection notification sub-processormay instruct an accessible device to either poll for any compatiblevending machines, or broadcast a Bluetooth beacon identifying theaccessible device, for example using a single-use ID so that theaccessible device is identifiable without revealing details of the useror their associated devices; such an ID may comprise a componentidentifying the purpose of the ID to enable detection by the vendingmachine, followed by the single use component unique to the user ortheir associated device; a compatible vending machine in accordance withembodiments of the present invention may then optionally recognize thesingle use ID and relay it back to the selection notificationsub-processor, thereby informing it that the user has accessible deviceswithin local wireless range of the vending machine. It will beappreciated that whilst the above makes reference to a vending machine,this is an example for the purposes of explanation, and these techniquesmay apply to any device not formally associated with a user or onlyintermittently associated with them, such as a car or train, a WiFi® orBluetooth® hotspot in a shop, a smart TV, or the like.

Optionally, devices outside the user's own deliver ecosystem may beselected. For example, a delivery device and/or a phone or other deviceof a friend or family member associated with the user (for examplefollowing registration of these people by the user) may be used toinform that friend or family member of the user's status, so that thefriend or family member can intervene. Optionally the user can set theconditions under which this occurs, and/or which friends or familymembers are notified. Similarly, devices within a predeterminedproximity of the user may be selected. For example, if the user is in agood mood, compatible devices within a predetermined radius of the usermay all synchronize a feature such as a color of a light, to signal tothese users that there is scope for an enjoyable social encounter.

Using one or more of these techniques, the selection notificationsub-processor may thus determine what devices are currently available todeliver a feedback action.

Typically, a feedback action will be specific to a particular devicewithin the delivery ecosystem or a pair of devices cooperating to fulfila function; consequently, for a proposed feedback action or selectedfeedback action, optionally the selection notification sub-processor mayonly poll the device or devices within the delivery ecosystem that arerelevant to that feedback action.

Similarly, it will be appreciated that certain devices within thedelivery ecosystem may provide input data to the feedback system that isused to generate the proposed feedback action; consequently such inputactivity from devices may be logged as indicating their accessibility,and/or it may be implicit from the proposed feedback action that certaindevices are currently accessible to the feedback system; in either case,a poll of the devices may not be necessary, or the receipt of input datamay be treated as an effective poll result if a polling scheme is inplace.

In the event that the device or devices relevant to that feedback actionare not available (e.g. do not respond to the poll), then optionally thefeedback processor/selection notification sub-processor may choose thenext proposed feedback action in the top N feedback actions, if multiplefeedback actions were proposed by the estimation processor. If norelevant device is available for a feedback action, then the feedbackprocessor may not implement any feedback action, and/or send anotification to the user to that effect, for example via a userinterface of the user's phone, or if the user's phone, as the accessibledevice for linking to other devices within the ecosystem, is notavailable, then notifying the user via a text or similar other mechanismthat will reach the user once they are contactable again.

In the event that the device or devices relevant to a feedback actionare available (i.e. do respond to the poll, or have responded to a pollwithin a predetermined preceding period of time during which it can beassumed the device is still accessible, or have contributed input datawithin a predetermined preceding period of time), then the feedbackprocessor will transmit one or more commands to the device or devicesfor implementing the feedback action as proposed by the estimationprocessor.

As noted above, the nature of the commands may depend upon the proposedaction and the target device or devices. In some cases, the simpleexistence of the command will be sufficient to specify the proposedaction, for example to turn a device on when it is off. In other cases,the command will need to specify the type of feedback action, forexample in relation to changing heater function, payload type, userinterface behavior or the like within the delivery system. In either ofthese cases, the command may need to specify the amount of feedbackaction, for example to specify the change in temperature, theconcentration of active ingredient or flavoring within the payload, orselected parameters for the user interface.

As noted above, the command may be directly to an accessible device, ormay be to request that an accessible device relays a command to anotherdevice within the ecosystem, or itself issues a command to such adevice; for example the feedback processor may instruct the user'smobile phone 100 to issue commands to the delivery device 10. Furtherdegrees of indirection may be envisaged, such as the user's mobile phoneissuing commands to a dock 200, which in turn may modify settings of thedelivery device when it is docked (for example to charge power orpayload). It will similarly be appreciated that the feedback processormay issue commands of different kinds to different devices; hence forexample a command may be issued directly to the mobile phone to changeaspects of its user interface, and to a dock 200 (either directly if itis capable, or via the phone), causing it to change a composition of apayload to be provided to the delivery device, and also change one ormore settings on the delivery device when it is docked. It will beappreciated that other permutations of commands such as these, whetherdirect, indirect, or a mix of the two, can be envisaged within thedelivery ecosystem.

As described elsewhere herein, will be appreciated that differentfeedback actions may relate to behavioral, pharmaceutical and/ornon-consumption aspects of the delivery ecosystem.

Behavioral feedback actions are typically focused on altering actionsand habits of the user relating to operations of, and/or interactionswith, a device within the delivery ecosystem other than operationsrelating to an amount or nature of an active ingredient delivered by thedelivery device itself, although this can occur in parallel. Examplesmay relate to the use of changes in flavor or flavor concentration,changing vapor mass delivery to modify inhalation behavior; modificationto scheduling schemes or reminders relating to delivery device usage orcorrelated with delivery device usage; changes to user interfaces,whether on the delivery device on another device in the deliveryecosystem, in terms of information provided, mode of feedback (e.g.haptic and/or visible such as colored lights, graphical themes, and/ormessages); for example providing a traffic light UI display on thedelivery device, such as an LED, to alert the user to how they are usingthe device), and the like.

Pharmaceutical feedback actions focus on pharmaceutical interventions tochange the state of the user, and typically relate to interventionsbased on active ingredients, such as the amount or type, and when theseare changed (for example reactively or pre-emptively, for example basedupon correlations between current user factors and future user states orfeedback actions), and the like. Such acts can also relate to selectingalternative modes of consumption, for example switching from vaping tosnus or vice versa.

Non-consumption feedback actions typically relate toactivating/controlling or simply recommending the use of devices notspecifically related to the consumption of the active ingredient, suchas aromatherapy systems/steamers, biofeedback devices, headphones (forexample activating noise cancellation, or modifying volume or musicselection), vehicle use (for example stress warnings, or routeselection/reselection to longer but less congested or slower routes),and the like.

The selection notification sub-processor may be comprised of one or morereal or virtual processors, and its functionality may be located ordistributed within the server and/or one or more devices within thedelivery ecosystem as appropriate.

Action Implementation

The action implementation sub-processor may be optional; for examplesome devices may accept commands directly with no further interpretationor processing required. In this case the action implementationsub-processor may be either thought of as not required, or having itsrole implemented by the feedback processor/selection and notificationsub-processor.

Meanwhile, in some cases the role of the action implementationsub-processor may in fact pre-exist within the device, which for exampleis capable of interpreting user interface commands to implement changesto the operation of the device; in this case, the commands from thefeedback processor may optionally simply replicate such user interfacecommands.

In other cases, the action implementation sub-processor may beseparately provided, for example by adapting a conventional processoraccording to suitable software instruction. Such an example may be anapp on a user's mobile phone, operable to receive commands and modifyone or more of aspects of the mobile phone and/or the app on the mobilephone, the delivery device, and/or one or more other devices in thedelivery ecosystem. Similarly, a dock 200 for the delivery device maycomprise such an action implementation sub-processor, as may somevarieties of delivery device.

The action implementation sub-processor operates to implement thefeedback action on the or each relevant device. Hence for example if acommand relating to a feedback action describes changing heatertemperature of the delivery device, then the action implementationsub-processor may change the power supply to the heater, and/or a dutycycle of the heater, to implement the specified change.

Similarly for example if a command relating to a feedback actiondescribes reducing ambient noise levels for the user, then the actionimplementation sub-processor for a pair of noise cancelling headphonesmay activate the noise cancelling function; the action implementationsub-processor for the user's mobile phone may reduce the volume level ofmusic being played into those headphones, and display a message to theuser suggesting that they seek to avoid sources of noise in theirenvironment.

The specific actions implemented by respective sub-processors may thusdepend on the nature of the proposed feedback action and the nature ofthe device within the delivery ecosystem, but will typically represent adirect translation of the proposed feedback action into the mechanism bywhich it may be enacted within device.

As noted previously herein, feedback actions may be accompanied orfollowed up by requests or opportunities for the user to report on theirefficacy. Alternatively or in addition, feedback actions may beaccompanied or followed up by positive reinforcement of the expectedstate change, for example through a message on a UI, or a change ofinterface color, haptic response or the like, or for example a positivegoal being met in an app for a wearable. The reinforcement may be asimple message indicating that the feedback has occurred, or may bebased upon measurements, for example to report that the user's heartrate has lowered, or to confirm that an action has worked well (bychanging the user's state, typically as evidenced by a change to one ormore user factors, or as self-reported by the user). The perceptionand/or expectation of a change in state engendered by such positivereinforcement can increase the effectiveness of at least some feedbackactions.

The action implementation sub-processor may be comprised of one or morereal or virtual processors, and its functionality may be located ordistributed within the server and/or one or more devices within thedelivery ecosystem as appropriate.

Processors

As noted previously, the obtaining processor, estimation processor, andfeedback processor (and any sub processors) may comprise one or morereal or virtual processors located within one or more servers and/orwithin the delivery ecosystem. Furthermore it will be appreciated thatthe demarcation of roles described herein is not fixed; for example theobtaining processor may receive information directly indicative of userstate (for example by user self-reporting), and so the first operationof a two operation process by the estimation processor could be bypassedor supplemented by the obtaining processor; similarly in this case, thefeedback processor may, for example, look up a corresponding proposedfeedback action. Hence in this example, the role of the estimationprocessor is carried out by the obtaining processor and the feedbackprocessor. Hence more generally these processors are representative oftasks that may be implemented by any processor under suitable softwareinstruction, and can equivalently be considered to comprise a datagathering task, a feedback proposal task (whether or not based on anexplicit estimation of the state of the user), and either a feedbacktraining task or a feedback delivery task.

In an embodiment of the description, as noted elsewhere herein data maybe collected from sensors on the delivery device and transmitted to acompanion device within the delivery ecosystem such as a user's phone.The data may optionally undergo at least some pre-processing by thedelivery device prior to transmission. As noted elsewhere herein, suchsensor data from the delivery device may then be associated with datafrom other sources (e.g. information relevant to the user's statebefore, during and/or after the recording of the sensor data, such asthe previously mentioned environmental, deterministic, contextual,neurological, physiological, indirect, and historical data) to generatemultiple source associated data. This data may be sent to a backendserver (e.g. at least part of the obtaining server function occurs atsuch a server). Alternatively the data may be processed with thesmartphone operating as the obtaining processor, and the function of theestimation processor may be implemented on one of the phone, the backend server, or a mix of the two. In this case the function of thefeedback server may similarly be implemented on one of the phone, theback end server, or a mix of the two (for example depending on thenature of the feedback or follow-on activities; actions such as sendingnotifications or product requests may be conducted by the back endserver in one embodiment, or the phone in another). The combinationwhere all three processors are implemented by the smartphone has theadvantage of privacy for the user because no data is sent to a back endserver. Alternatively for example, the function of the estimationprocessor may be performed by the server as this is likely to becomputationally complex; meanwhile the inputs to the estimationprocessor may be machine readable only and optionally associated with ananonymized request (e.g. a single use request number), so that the datacan be processed without the user of the back end server being able todetermine the inputs or estimated state of a particular user.

Summary Embodiments

In a summary embodiment of the present description, a user feedbacksystem for a user of a delivery device within a delivery ecosystem (1),comprises the following.

Firstly, an obtaining processor (1010) adapted to obtain one or moreuser factors indicative of a user state, wherein said one or more userfactors are based upon at least a first aspect of the user's situationseparate to their handling or operation of the delivery device, asdescribed elsewhere herein. It will be appreciated that consequently theuser factors may relate to situations at least partially characterizedby one or more of indirect/historical data, contextual data andenvironmental or deterministic data as described elsewhere herein.

Secondly, an estimation processor (1020) adapted to identify acorresponding feedback action expected to alter a state of the user asindicated at least in part by the or each user factor, as describedelsewhere herein.

In an instance of the summary embodiment, the user feedback systemcomprises a feedback processor (1030) adapted to select at least a firstfeedback action identified by the estimation processor for at least afirst device within the delivery ecosystem, as described elsewhereherein.

In this instance, optionally the feedback processor may be adapted tocause a modification of one or more operations of at least a firstdevice within the delivery ecosystem according to the or each selectedfeedback action, as described elsewhere herein. Subsequently in thiscase, optionally the device within the delivery ecosystem for which oneor more operations is modified is the delivery device (10), as describedelsewhere herein.

In an instance of the summary embodiment, data relating to at least afirst aspect of the user's situation upon which at least a first of theuser factors is based is obtained from a physical sensor.

In this instance, optionally such a physical sensor is a microphone, andthe obtained data relates to one or more selected from the listconsisting of background noise levels, background media playback (e.g.from music or video), and the user's speech (whether vocal tone orspoken content), as described elsewhere herein.

Similarly in this instance, optionally such a physical sensor is acamera, and the obtained data relates to one or more selected from thelist consisting of whether the user is alone or not, whether the user iswith one or more known individuals, and the user's facial expression, asdescribed elsewhere herein.

In an instance of the summary embodiment, data relating to at least afirst aspect of the user's situation upon which at least a first of theuser factors is based is obtained from a textual analysis of contentthat the user has interacted with, as described elsewhere herein.

In this instance, optionally the content comprises one or more selectedfrom the list consisting of social media posts the user is reading orsending, news articles the user is reading, websites the user isvisiting, searches the user is making online, test messages the user isreading or sending, content of calls the user is participating in, andthe content of conversations the user is having, as described elsewhereherein.

Similarly in this instance, optionally the content comprises calendarinformation for the user, as described elsewhere herein. In this case,optionally the calendar information indicates one or more selected fromthe list consisting of a person the user is currently or about to meet,an event the user is currently or about to attend, a location the useris currently or about to visit, and a task the user is currently orabout to perform, as described elsewhere herein.

Again similarly in this instance, optionally content comprises one ormore user responses to a questionnaire relating to the state of theuser, as described elsewhere herein.

In an instance of the summary embodiment, data relating to at least afirst aspect of the user's situation upon which at least a first of theuser factors is based is obtained from the user's interaction withdevices within the delivery ecosystem other than the delivery device(10), as described elsewhere herein.

In this instance, optionally the user's interaction comprises one ormore selected from the list consisting of a choice of app used by theuser, a choice of device by the user to interact with, a duration ofinteraction by the user with a chosen app or device, a type ofinteraction by the user with a chosen app or device, and a type of mediaconsumed with a chosen app or device, as described elsewhere herein.

In an instance of the summary embodiment, data relating to at least afirst aspect of the user's situation upon which at least a first of theuser factors is based is obtained from data indicative of the user'senvironment, as described elsewhere herein.

In this instance, optionally the data indicative of the user'senvironment is based upon one or more selected from the list consistingof the user's current or next location, whether the user is in an openor enclosed space, whether the user is in daylight or artificial light,the user's current mode of transport, and the weather at the user'slocation, as described elsewhere herein.

In an instance of the summary embodiment, data relating to at least afirst aspect of the user's situation upon which at least a first of theuser factors is based is obtained from data indicative of the user'ssocial situation, as described elsewhere herein.

In this instance, optionally the data indicative of the user's socialsituation is based upon one or more selected from the list consisting ofwhether the user is alone or with one or more others, whether the useris with one or more work colleagues, whether the user is with one ormore friends, whether the user is with one or more family members, andwhether the user is with one or more children, as described elsewhereherein.

In an instance of the summary embodiment, data relating to at least afirst aspect of the user's situation upon which at least a first of theuser factors is based is obtained from data indicative of a past historyof the user, as described elsewhere herein.

In this instance, optionally the data indicative of the past history ofthe user is based on one or more selected from the list consisting ofthe user's place of birth, a cultural background of the user, a religionof the user, a purchase history of the user, and settings preferences ofthe user for one or more devices of the delivery ecosystem, as describedelsewhere herein.

In an instance of the summary embodiment, the estimation processor isoperable to use a plurality of user factors as input when identifying acorresponding feedback action, as described elsewhere herein.

In this instance, optionally at least a further user factor (i.e. one ofthe plurality other than the at least first) is selected from the listconsisting of a user factor based upon a self-reported indication of auser's state from the user, a user factor based upon a physiologicalsensor data from the user, and a user factor based upon motion and/orlocation analysis, as described elsewhere herein.

Similarly in this instance, optionally at least a further user factor isbased upon sensor data from the delivery device (10), as describedelsewhere herein.

In an instance of the summary embodiment, the estimation processor doesnot generate an explicit estimation of user state as an interimoperation in the identification of the one or more proposed feedbackactions, as described elsewhere herein.

In an instance of the summary embodiment, the estimation processor usesdifferent respective machine learning systems responsive to thecomposition of the one or more user factors provided as input to theestimation processor, as described elsewhere herein.

In an instance of the summary embodiment, the estimation processor isoperable to generate one or more proposed feedback actions relating toone or more selected from the list consisting of a behavioral feedbackaction for affecting at least a first behaviors of the user,pharmaceutical feedback action for affecting the consumption of anactive ingredient by the user, and a non-consumption feedback action foraffecting one or more non-consumption operations of the deliveryecosystem, as described elsewhere herein.

In an instance of the summary embodiment, the delivery ecosystemcomprises one or more selected from the list consisting of one or moredelivery devices (10), one or more mobile terminals (100), one or morewearable devices (400), and one or more docking units (200) for the oreach delivery device, as described elsewhere herein.

Meanwhile, in an instance of the summary embodiment, the functionalityof one or more of the obtaining processor, estimation processor, andfeedback processor is provided at least in part by one or moreprocessors located within one or more devices (10, 100, 200, 300, 400)of the delivery ecosystem (1), or the remote server (1000).

Referring now to FIG. 7 , in a summary embodiment of the presentdescription a user feedback method for a user of a delivery devicewithin a delivery ecosystem comprises the following operations.

In s710, obtaining one or more user factors indicative of a state of theuser. As described previously herein, this may be a function of theobtaining processor (1010), or may be performed by one or moredevices/processors/data sources operating collectively or in parallel asthe obtaining processor or for the obtaining processor, or which mayshare such functionality with the obtaining processor.

Notably, the one or more user factors are based upon at least a firstaspect of the user's situation separate to their handling or operationof the delivery device. As noted elsewhere herein, such aspects of theuser's situation may relate to one or more of indirect or historicalaspects, circumstantial aspects, or environmental or deterministicaspects. Such aspects may have a degree of overlap with each other, orwith usage or physiological aspects (e.g. chronic health may be both aphysiological aspect and also historic, circumstantial or deterministic,depending on the health matter and how it influences the user'ssituation).

In s720, identifying a corresponding feedback action expected to alter astate of the user as indicated at least in part by the or each userfactor. As described previously herein, this may be a function of theestimation processor (1020). More generally, it may be a function of aprocessor of the feedback system, typically located within a serverremote to the delivery ecosystem, but optionally located in one or moredevices of the delivery ecosystem operating collectively or in parallelas the estimation processor or for the estimation processor, or whichmay share such functionality with the estimation processor.

It will be apparent to a person skilled in the art that variations inthe above method corresponding to operation of the various embodimentsof the apparatus/system as described and claimed herein are consideredwithin the scope of the present disclosure, including but not limitedto:

-   -   in an instance of the summary embodiment, selecting at least a        first feedback action for at least a first device within the        delivery ecosystem, as identified in the estimation operation,        that is expected to alter the estimated state of a user. As        described previously herein, this may be a function of the        feedback processor (1030), which in turn may comprise one or        more of the selection and notification sub-processor and the        action implementation sub-processor. More generally, it may be a        function of a processor of the feedback system, typically        located within a server remote to the delivery ecosystem, but        optionally located in one or more devices of the delivery        ecosystem operating collectively or in parallel as the feedback        processor or a sub-processor thereof or for such a processor, or        which may share such functionality with the feedback processor        or a sub-processor thereof, as described elsewhere herein;    -   hence in an instance of the summary embodiment, selecting at        least a first feedback action identified by the estimation        operation for at least a first device within the delivery        ecosystem, as described elsewhere herein;    -   in this instance, optionally causing a modification of one or        more operations of at least a first device within the delivery        ecosystem according to the selected feedback action, as        described elsewhere herein;    -   in this instance, optionally the device within the delivery        ecosystem for which one or more operations is modified is the        delivery device, as described elsewhere herein;    -   in an instance of the summary embodiment, data relating to at        least a first aspect of the user's situation upon which at least        a first of the user factors is based is obtained from at least a        first physical sensor, as described elsewhere herein;    -   in an instance of the summary embodiment, data relating to at        least a first aspect of the user's situation upon which at least        a first of the user factors is based is obtained from a textual        analysis of content that the user has interacted with, as        described elsewhere herein;    -   in this instance, optionally the content comprises calendar        information for the user, as described elsewhere herein;    -   in this instance, optionally the content comprises one or more        user responses to a questionnaire relating to the state of the        user, as described elsewhere herein;    -   in an instance of the summary embodiment, data relating to at        least a first aspect of the user's situation upon which at least        a first of the user factors is based is obtained from the user's        interaction with devices within the delivery ecosystem other        than the delivery device (10), as described elsewhere herein;    -   in an instance of the summary embodiment, data relating to at        least a first aspect of the user's situation upon which at least        a first of the user factors is based is obtained from data        indicative of the user's environment, as described elsewhere        herein;    -   in an instance of the summary embodiment, which data relating to        at least a first aspect of the user's situation upon which at        least a first of the user factors is based is obtained from data        indicative of the user's social situation, as described        elsewhere herein;    -   in an instance of the summary embodiment, data relating to at        least a first aspect of the user's situation upon which at least        a first of the user factors is based is obtained from data        indicative of a past history of the user, as described elsewhere        herein;    -   the estimation operation comprises using a plurality of user        factors as input when identifying a corresponding feedback        action, as described elsewhere herein;    -   in this instance, optionally at least a further user factor is        selected from the list consisting of a user factor based upon a        self-reported indication of a user's state from the user, a user        factor based upon a physiological sensor data from the user, and        a user factor based upon motion and/or location analysis, as        described elsewhere herein;    -   in this instance, optionally at least a further user factor is        based upon sensor data from the delivery device (10), as        described elsewhere herein;    -   in an instance of the summary embodiment, the estimation        operation comprises generating one or more proposed feedback        actions relating to one or more selected from the list        consisting of a behavioral feedback action for affecting at        least a first behavior of the user, a pharmaceutical feedback        action for affecting the consumption of an active ingredient by        the user, and a non-consumption feedback action for affecting        one or more non-consumption operations of the delivery        ecosystem, as described elsewhere herein; and    -   in an instance of the summary embodiment, the one or more user        factors include one or more user factors selected from the group        comprising: one or more user inhalation characteristics, output        from one or more motion sensors configured to detect        micromovements or tremors of a user, and the output from one or        more sensors configured to detect when and/or how a user is        holding a device of the delivery ecosystem, as described        elsewhere herein.

It will be appreciated that the above methods may be carried out onconventional hardware suitably adapted as applicable by softwareinstruction or by the inclusion or substitution of dedicated hardware.Examples of such hardware have been described previously herein, forexample in relation to server 1000 and the devices of the deliveryecosystem 1.

Thus the required adaptation to existing parts of a conventionalequivalent device may be implemented in the form of a computer programproduct comprising processor implementable (computer executable)instructions stored on a non-transitory machine-readable medium such asa floppy disk, optical disk, hard disk, solid state disk, PROM, RAM,flash memory or any combination of these or other storage media, orrealized in hardware as an ASIC (application specific integratedcircuit) or an FPGA (field programmable gate array) or otherconfigurable circuit suitable to use in adapting the conventionalequivalent device. Separately, such a computer program may betransmitted via data signals on a network such as an Ethernet, awireless network, the Internet, or any combination of these or othernetworks.

1. A user feedback system for a user of a delivery device within adelivery ecosystem, comprising: an obtaining processor adapted to obtainone or more user factors indicative of a user state, wherein the one ormore user factors are based upon at least a first aspect of a situationof the user separate to handling or operation of the delivery device bythe user; and an estimation processor adapted to identify acorresponding feedback action expected to alter the user state asindicated at least in part by the one or more user factors.
 2. The userfeedback system according to claim 1, further comprising a feedbackprocessor adapted to select at least a first feedback action identifiedby the estimation processor for at least a first device within thedelivery ecosystem.
 3. The user feedback system according to claim 2,wherein the feedback processor is adapted to cause a modification of oneor more operations of at least a first device within the deliveryecosystem according to the selected at least first feedback action. 4.The user feedback system according to claim 3, wherein the at leastfirst device within the delivery ecosystem for which one or moreoperations is modified is the delivery device.
 5. The user feedbacksystem according to claim 1, wherein data relating to at least the firstaspect of the situation of the user upon which at least the first of theuser factors is based is obtained from a physical sensor.
 6. The userfeedback system according to claim 5, wherein the physical sensor is amicrophone, and the obtained data relates to one or more selected fromthe group consisting of: background noise levels; background mediaplayback; and speech of the user.
 7. The user feedback system accordingto claim 5, wherein the physical sensor is a camera, and the obtaineddata relates to one or more selected from the group consisting of:whether the user is alone or not; whether the user is with one or moreknown individuals; and a facial expression of the user.
 8. The userfeedback system according to claim 1, wherein data relating to at leastthe first aspect of the situation of the user upon which at least thefirst of the user factors is based is obtained from a textual analysisof content that the user has interacted with.
 9. The user feedbacksystem according to claim 8, wherein the content comprises one or moreselected from the group consisting of: social media posts the user isreading or sending; news articles the user is reading; websites the useris visiting; searches the user is making online; text messages the useris reading or sending; content of calls the user is participating in;and content of conversations the user is having.
 10. The user feedbacksystem according to claim 8, wherein the content comprises calendarinformation for the user.
 11. The user feedback system according toclaim 10, wherein the calendar information indicates one or moreselected from the group consisting of: a person the user is currently orabout to meet; an event the user is currently or about to attend; alocation the user is currently or about to visit; and a task the user iscurrently or about to perform.
 12. The user feedback system according toclaim 8, wherein the content comprises one or more user responses to aquestionnaire relating to the user state.
 13. The user feedback systemaccording to claim 1, wherein data relating to at least the first aspectof situation of the user upon which at least the first of the userfactors is based is obtained from interaction of the user with deviceswithin the delivery ecosystem other than the delivery device.
 14. Theuser feedback system according to claim 13, wherein the interaction ofthe user comprises one or more selected from the group consisting of: achoice of app used by the user; a choice of device by the user tointeract with; duration of interaction by the user with a chosen app ordevice; type of interaction by the user with a chosen app or device; andtype of media consumed with a chosen app or device.
 15. The userfeedback system according to claim 1, wherein data relating to at leastthe first aspect of the situation of the user upon which at least thefirst of the user factors is based is obtained from data indicative ofan environment of the user.
 16. The user feedback system according toclaim 15, wherein the data indicative of environment of the user isbased upon one or more selected from the group consisting of: a currentor next location of the user; whether the user is in an open or enclosedspace; whether the user is in daylight or artificial light; a currentmode of transport of the user; and weather at the location of the user.17. The user feedback system according to claim 1, wherein data relatingto at least the first aspect of the situation of the user upon which atleast the first of the user factors is based is obtained from dataindicative of a social situation of the user.
 18. The user feedbacksystem according to claim 17, wherein the data indicative of the socialsituation of the user is based upon one or more selected from group listconsisting of: whether the user is alone or with one or more others;whether the user is with one or more work colleagues; whether the useris with one or more friends; whether the user is with one or more familymembers; and whether the user is with one or more children.
 19. The userfeedback system according to claim 1, wherein data relating to at leastthe first aspect of the situation of the user upon which at least thefirst of the user factors is based is obtained from data indicative of apast history of the user.
 20. The user feedback system according toclaim 19, wherein the data indicative of the past history of the user isbased on one or more selected from the group consisting of: a place ofbirth of the user; a cultural background of the user; a religion of theuser; a purchase history of the user; and settings preferences of theuser for one or more devices of the delivery ecosystem.
 21. The userfeedback system according to claim 1, wherein the estimation processoris operable to use a plurality of user factors as input when identifyinga corresponding feedback action.
 22. The user system according to claim21, wherein at least a further user factor is selected from the groupconsisting of: a user factor based upon a self-reported indication ofthe user state from the user; a user factor based upon a physiologicalsensor data from the user; and a user factor based upon analysis of atleast one of motion or location.
 23. The user system according to claim21, wherein at least a further user factor is based upon sensor datafrom the delivery device.
 24. The user feedback system according toclaim 1, wherein the estimation processor does not generate an explicitestimation of user state as an interim operation in the identificationof the one or more proposed feedback actions.
 25. The user feedbacksystem according to claim 1, wherein the estimation processor usesdifferent respective machine learning systems responsive to compositionof the one or more user factors provided as input to the estimationprocessor.
 26. The user feedback system according to claim 1, whereinthe estimation processor is operable to generate one or more proposedfeedback actions relating to one or more selected from the groupconsisting of: a behavioral feedback action for affecting at least afirst behavior of the user; a pharmaceutical feedback action foraffecting consumption of an active ingredient by the user; and anon-consumption feedback action for affecting one or morenon-consumption operations of the delivery ecosystem.
 27. The userfeedback system according to claim 1, wherein the delivery ecosystemcomprises one or more selected from the group consisting of: one or moredelivery devices; one or more mobile terminals; one or more wearabledevices; and one or more docking units for the one or more deliverydevices.
 28. The user feedback system according to claim 1, whereinfunctionality of one or more of the obtaining processor, the estimationprocessor, or a feedback processor is provided at least in part by oneor more processors located within one or more devices of the deliveryecosystem, or the remote server.
 29. A user feedback method for a userof a delivery device within a delivery ecosystem comprises: obtainingone or more user factors indicative of a user state, wherein the one ormore user factors are based upon at least a first aspect of a situationof the user separate to handling or operation of the delivery device bythe user; and estimating by identifying a corresponding feedback actionexpected to alter the user state as indicated at least in part by theone or more user factors.
 30. The user feedback method according toclaim 29, further comprising selecting at least a first feedback actionidentified by the estimating for at least a first device within thedelivery ecosystem.
 31. The user feedback method according to claim 30,further comprising causing a modification of one or more operations ofat least a first device within the delivery ecosystem according to theselected feedback action.
 32. The user feedback method according toclaim 31, wherein the device within the delivery ecosystem for which oneor more operations is modified is the delivery device.
 33. The userfeedback method according to claim 29, wherein data relating to at leastthe first aspect of the user s situation of the user upon which at leastthe first of the user factors is based is obtained from at least a firstphysical sensor.
 34. The user feedback method according to claim 29,wherein data relating to at least the first aspect of the user'ssituation upon which at least the first of the user factors is based isobtained from a textual analysis of content that the user has interactedwith.
 35. The user feedback method according to claim 34, in which thecontent comprises calendar information for the user.
 36. The userfeedback method according to claim 34, wherein the content comprises oneor more user responses to a questionnaire relating to the user state.37. The user feedback method according to claim 29, wherein datarelating to at least the first aspect of the situation of the user uponwhich at least the first of the user factors is based is obtained frominteraction by the user with devices within the delivery ecosystem otherthan the delivery device.
 38. The user feedback method according toclaim 29, wherein data relating to at least the first aspect of thesituation of the user upon which at least the first of the user factorsis based is obtained from data indicative of an environment of the user.39. The user feedback method according to claim 29, wherein datarelating to at least the first aspect of the situation of the user uponwhich at least the first of the user factors is based is obtained fromdata indicative of a social situation of the user.
 40. The user feedbackmethod according to claim 29, wherein data relating to at least thefirst aspect of the situation of the user upon which at least the firstof the user factors is based is obtained from data indicative of a pasthistory of the user.
 41. The user feedback method according to claim 29,wherein the estimating comprises using a plurality of user factors asinput when identifying a corresponding feedback action.
 42. The userfeedback method according to claim 41, wherein at least a further userfactor is selected from the group consisting of: a user factor basedupon a self-reported indication of the user state from the user; a userfactor based upon a physiological sensor data from the user; and a userfactor based upon analysis of at least one of motion or location. 43.The user feedback method according to claim 41, wherein at least afurther user factor is based upon sensor data from the delivery device.44. The user feedback method according to claim 29, wherein theestimating comprises generating one or more proposed feedback actionsrelating to one or more selected from the group consisting of: abehavioral feedback action for affecting at least a first behavior ofthe user; a pharmaceutical feedback action for affecting consumption ofan active ingredient by the user; and a non-consumption feedback actionfor affecting one or more non-consumption operations of the deliveryecosystem.
 45. A computer system comprising at least one processor andmemory adapted to perform the method of claim
 29. 46. A non-transitorycomputer-readable storage medium storing a computer program productwhich, when executed by a computer, causes the computer to perform themethod of claim 29.